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[57] ABSTRACT 

In an electronic mail system environment, a system and 
method for automatically checking recipients' names, pro- 
viding message flags, providing custom forms, and provid- 
ing an auto response feature. Recipients' names are resolved 
in the background, while the user of the e-mail system is 
composing the message. The user easily resolves ambiguous 
names by using a context menu. The resolved ambiguous 
names are automatically used to create nicknames, which are 
used to resolve ambiguous names in the future. Message 
flags allow a sender or recipient to identify required follow- 
up action and a deadline. The recipient may use the message 
flags to quickly determine which messages require follow- 
up action. The e-mail system notifies a recipient when a due 
date is approaching or when a follow-up action is past due. 
A custom forms feature allows a user to create and share 
custom forms without requiring the form to be published or 
installed by other user. The custom form's attributes are 
transmitted to the recipient as an element of the e-mail 
message. An autoresponse feature allows a sender to create 
a message that includes voting buttons corresponding to the 
possible responses to a query. A recipient replies by selecting 
one of the voting buttons. The recipient's vote is automati- 
cally tallied in the sender's copy of the message, thus 
allowing the sender to view a vote tally, a list of the 
recipients, and their response. 
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SYSTEM AND METHOD FOR RESOLVING 
NAMES IN AN ELECTRONIC MESSAGING 
ENVIRONMENT 

TECHNICAL FIELD 

The present invention relates to a system and method for 
creating and sending electronic mail, and more particularly 
relates to a system and method for simplifying the processes 
of resolving recipient names, indicating action items, utiliz- 
ing custom forms, and tallying replies from a group of 
recipients. 

BACKGROUND OF THE INVENTION 

Electronic mail, or e-mail, is a service that transmits 
electronic messages from one computer to another. These 
messages may be simple text messages or more complex 
messages containing documents and data of various types. 
The transmission of e-mail messages may range from trans- 
mission over a short distance, such as over a local area 
network between employees in adjoining offices, to trans- 
mission over extremely long distances, such as over the 
global Internet between users on different continents. 

Generally, to send an e-mail message via an e-mail 
system, a user opens an e-mail program module and types a 
message and other information into an e-mail form. The 
e-mail form contains a number of fields for the recipients' 
addresses, the subject of the message, and the message itself. 
The user may also attach separate files to the e-mail mes- 
sage. Before sending the e-mail message, the user must enter 
the recipient's e-mail address, which is used by the e-mail 
system to route the message to the intended recipient. 

After composing an e-mail message and entering the 
recipient's address, the user sends the message by invoking 
a "send" command. The e-mail system then sends the 
message to the recipient. At the recipient's computer, the 
recipient typically will receive a visual or auditory cue, such 
as a ringing bell, when an e-mail message has been received 
in the recipient's inbox. The recipient may then open the 
e-mail program and view a list of the messages in the inbox. 
The recipient may view the complete text of a message by 
selecting and opening that message. 

E-mail is becoming increasingly popular because it is a 
quick, convenient, and easy way to exchange information 
and communicate with others. E-mail offers numerous 
advantages over other forms of communication. For 
example, e-mail is less intrusive than a telephone call 
because the recipient of an e-mail message may wait until a 
convenient time to retrieve and respond to the message 
rather than being immediately interrupted. Another advan- 
tage of e-mail is the ability to communicate with large 
groups of people by sending a single e-mail message to 
multiple recipients. Still another advantage of e-mail is the 
ability of attaching documents in electronic format to an 
e-mail message. 

E-mail messages are composed in the context of a "form." 
A form is an object that is used to display a message in a 
structured format. An e-mail form typically provides a 
plurality of fields, including an address field, a "From" field, 
a "Subject" field, a "cc" field, and a "Body" field. The user 
of the e-mail system composes the message by entering data 
into some or all of the fields on the form. 

E-mail forms typically incorporate verbs, which are com- 
mands that a form is capable of executing. Typical verbs 
include commands such as reply, forward, open, and print. 
For example, a recipient may generate a reply to an e-mail 
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message by clicking on a reply button. In response to the 
reply command, the e-mail program carries out the instruc- 
tions associated with the "reply" verb. This includes copying 
the data in the address field of the incoming message to the 
5 "From" field of the reply, copying the data in the "From" 
field of the incoming message to the address field of the 
reply, and adding "Re:" before the data in the "Subject" 
field. 

Although e-mail provides a valuable and useful tool, 
current e-mail systems are not without their drawbacks. For 
instance, an e-mail system must have a unique, specific 
destination address in order to deliver an e-mail message to 
the correct recipient, in many cases, e-mail addresses are not 
intuitive derivatives of a person's name and may be difficult 
for the user to remember. Also, because the address must be 

■^^ specific, a typographical error entered by the user will result 
in the message being misdelivered or not delivered at all. 

Before the e-mail system can send a message, all of the 
names in the address field must be "resolved," or matched 
with the valid address of a particular user. In most e-mail 

20 systems, the recipients' names are resolved when the user 
invokes the "send" command or a "check names" command. 
In either case, the e-mail system resolves unambiguous 
names without user intervention and prompts the user to 
resolve ambiguous names by selecting the correct name 

25 from a short list. 

As an example, Jim Peterson is sending an e-mail mes- 
sage to his friend Dave. In the address field of the message, 
Jim enters the name "Dave." An address book or directory, 
which is stored on the server, is used by the e-mail system 

30 to match the name "Dave" with the appropriate recipient. In 
a small company or organization with only one user named 
Dave, entering "Dave" in the address field would be unam- 
biguous to the e-maU system and the e-mail system would 
match the name "Dave" to the correct, unique e-mail 

35 address. However, in a company or organization with mul- 
tiple Daves, the name must be resolved to the correct Dave, 
lliis method of resolving names is inconvenient because the 
user must execute an extra step to resolve the names before 
the message is sent. This is especially inconvenient if a user 

40 only sends mail to one "Dave" although the address book 
contains many "Daves." Also, as companies and organiza- 
tions expand, the e-mail system address book continues to 
grow, thereby increasing the chances for ambiguity. The 
potential is created for false matches resulting in misdirected 

45 e-mail. 

One attempt to simplify the process of resolving names is 
to implement a feature that monitors the user's typing of 
characters in the address field and volunteers the fiill name 
when the user types enough characters to uniquely identify 

50 one recipient. Alternatively, in another attempted solution, 
the user can type in a number of characters and get a list of 
recipients whose name begins with the characters typed in 
by the user. Neither of these solutions provides a satisfactory 
solution to the problem of resolving names. First, a long 

55 string of characters may need to be entered before a unique 
name is found. Also, for certain names, such as John Smith, 
a unique name may never be found even if the entire name 
is entered. In addition, the user must enter the name exactly 
as it appears in the directory even if one part of a name is 

60 more unique than another part of a name. For example, 
"MacDonald" is probably more unique than "John," but a 
user must enter the name as "John Mac . . ." if that is how 
the name appears in the directory. Furthermore, these 
attempted solutions require the user's attention to complete 

65 the resolution of the names. 

In addition to the drawbacks associated with verifying 
e-mail addresses, current e-mail systems do not provide the 
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user with an effective way to organize and manage the user's 
e-mail inbox. Many businesses rely on an e-mail system as 
one of the main modes of communication between 
individuals, resulting in users often having to deal with large 
numbers of e-mail messages. In cases where an e-mail user 5 
has received messages that delegate responsibilities or 
request specific follow-up actions, these messages may 
easily be lost in a flood of other e-mail messages. Even if a 
recipient has a manageable amount of e-mail messages in his 
or her inbox, requests for action are often buried in the body 
of an e-mail message and the recipient may not realize that 
an action has been requested. 

E-mail systems usually provide only rudimentary mecha- 
nisms for identifying and sorting important messages that 
require some sort of action. For example, one mechanism for 
identifying and sorting important messages is for the sender 
of the message to set a priority for the message that the 
recipient will receive with the message. In the alternative, 
the sender may provide information about the e-mail mes- 
sage in the subject line. For example, the sender may set the 
priority as "urgent" for a respective e-mail message or type 20 
"urgent" in the "Subject" field. However, this mechanism of 
setting priorities is ineffective because the e-mail message 
may not require immediate action. The recipient may open 
and read the message, and then file the message in a 
"follow-up" folder. Thus, there is the possibiHty that the 25 
recipient will forget to take the action at a later time. 

Another mechanism for identifying and sorting important 
messages is for the recipient of the message to forward the 
message to himself and change the priority of the message 
or subject of the message to the priority or subject desired by 30 
the recipient. However, re -prioritizing by the recipient suf- 
fers from the drawback of the recipient spending extra time 
and effort to execute the steps of sending a message back to 
himself. Thus, the previous solutions to organize and iden- 
tify important e-mail messages, such as those that require 35 
action, only achieve adequate results at best. 

Another drawback of current e-mail systems is the diffi- 
culty in creating and using customized e-mail forms, ITiere 
are times when a user feels that the fields on an e-mail form 
simply do not meet their requirements and that it would be 40 
useful to add user-specified fields. For example, Jim is 
working with Shirley to develop a casing for the radio she 
is designing. E-mail messages containing information about 
the dimensions of the radio are constantly being sent 
between the two. Using a normal e-mail message, the 45 
information is buried within the message making it difficult 
to find. As a result, Jim and Shirley would like to create a 
customized e-mail form with added fields for the length, 
width, and height of the casing. 

Currently, to add fields to an e-mail message, a custom 50 
form is created using a separate apphcation program. After 
the form is created and defined, the form must be placed on 
a central server for distribution and installed in each user's 
form registry. Usually, placing the form on the server must 
be approved and executed by the management information 55 
systems (MIS) department. Thus, placing a form on a server 
may involve some delay and bureaucratic problems After the 
form is placed on the server, any user of the form must install 
the form before an e-mail message using this form may be 
displayed on their screen. For instance, in the above 60 
example, Jim would have to install the form on his computer 
before receiving an e-mail message from Shirley utilizing 
the form. Therefore, using a form with user-specified fields 
may be time-consuming and annoying because the form 
must be created and placed on a server, and the form must 65 
be installed on a user's computer before the form can be 
used. 
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Another drawback of current e-mail systems is an inabil- 
ity to effectively organize responses to an e-mail message 
from a group of people. For example, when working with a 
large group, a user is often required to interact with other 
group members to make decisions. Using an e-mail message 
to pose a question to a large group reduces the difficulty of 
contacting each member of the group for their response. 
Instead of directly contacting each member of the group, one 
e-mail message requesting a response can be sent to every 
member of the group. Each recipient types in their response 
and sends a reply e-mail message to the user. However, the 
user still has the task of organizing the replies as they are 
received and tallying the responses to determine the group 
consensus. Thus, the user is required to open every reply, 
read it to determine the response, and tally the responses to 
decide the consensus of the group. Current e-mail systems 
do not provide a mechanism for automatically tallying the 
responses to a question. Instead, the user must manually 
organize the responses, typically by creating folders for each 
of the different responses, by creating a spreadsheet with the 
different responses and the number of replies associated with 
each response, or simply by tracking the responses on paper 
However, these solutions require time and effort on the part 
of the user and do not directly address the issue of tallying 
responses. 

Therefore, there is a need in the art for an e-mail system 
that is easier to use and provides more useful organizational 
features than current e-mail systems. 

In particular, there is a need for an e-mail system that 
simplifies the process of resolving recipient addresses and 
minimizes the input required from the user. 

There is also a need for an e-mail system that provides 
more useful organizational features for the recipient by 
distinctly identifying important e-mail messages, such as 
messages that require follow-up action. 

There is a further need for an e-mail system that provides 
the ability to use custom forms with user-specified fields 
without requiring the forms to be created and stored on a 
server. 

There is still a further need for an e-mail system that 
provides more useful organizational features by automati- 
cally tallying the responses to a question posed to a group of 
e-mail users. 

SUMMARY OF THE INVENTION 

The present invention satisfies the above described needs 
by providing an improved system and method for 
composing, processing, and organizing electronic mail mes- 
sage items. ITie present invention automatically resolves 
recipient display names while the user is composing the 
message. ITie invention provides multiple options for 
resolving ambiguous names and automatically creates nick- 
names based on how ambiguous names are resolved. The 
present invention also allows a sender or recipient to indi- 
cate specific follow-up action associated with a message. 
The message flag may be accompanied by a due date, which 
generates reminders and past due notices. The present inven- 
tion also provides an efficient method for sharing custom 
e-mail forms with other users. A description of the custom 
form is transmitted as part of the e-mail message and 
displayed by the recipient's computer. The present invention 
also automatically tallies multiple responses to a query. The 
sender sends a message that includes a query and specific 
choices for the response. The recipient creates a reply by 
selecting one of the predefined choices. When the original 
sender receives the reply, the sent mail copy of the message 
is updated to tally the votes. 
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Generally described, in one aspect, the present invention property is retrieved and the message is displayed in the 

provides a method for resolving a display name associated context of the corresponding form. If the message item does 

with an intended recipient of a message item, which is sent not include a form property, standard form data is retrieved 

in the context of an electronic mail system. The method from a form registry and the message item is displayed in the 

includes receiving the display name in an address field and 5 context of the standard form. 

determining whether the display name uniquely matches one In yet another aspect, the present invention provides a 

of a plurality of registered users of the electronic mail method for sending a message item to a plurality of recipi- 

system. If the entered address data uniquely matches one of ents and automatically tallying the responses. A message 

the registered users, data conresponding to the matching item is created, and includes a query and a plurality of 

registered user is displayed. Otherwise, ambiguous address lO predefined responses. The message is transmitted to the 

data is displayed. recipients. When a reply is received, the response included 

More particulariy described, the present invention pro- in the reply is automatically tallied, 

vides a method for using nicknames to resolve the name of The original message item can include an autoresponse 

an intended recipient of a message item. The method property. If so, response data corresponding to the pre- 

includes receiving a display name in an address field and 15 defined responses is received from the sender of the message 

determining whether the display name corresponds to a item. The response data is then stored in the autoresponse 

previously stored nickname. If so, nickname data corre- property. Responses are tallied by reading identification data 

sponding to a registered user associated with the nickname in the reply message and locating a sent mail copy of the 

is displayed. If no nickname is found, the method determines original message. A voter property is located in the sent mail 

whether the display name uniquely matches one of a plu- 20 copy and the reply data is stored in the voter property of the 

rality of registered users of the electronic mail system. If so, sent mail copy. 

recipient data corresponding to the matching registered user More particularly described, the present invention pro- 
is displayed. If there is no unique match, the ambiguous vides a method for selecting one of a plurality of predefined 
address data is displayed. responses in reply to a message item that includes a query. 

In another aspect, the present invention provides a method A message is opened and a plurality of voting buttons is 

for including a flag with the message item, which is trans- displayed. Each voting button corresponds to one of the 

mitted in an electronic mail system. Flag data is received and predefined responses. Input corresponding to the selection of 

stored as one of a plurality of message properties. The e-mail one of the voting buttons is received and a reply message 

message item is then transmitted to a recipient. item is created. Data corresponding to the selected voting 

The message item can also include a combination of a due ^° button is stored in one of the properties of the reply message, 

date property and the message flag property. The computer It is therefore an object of the present invention to provide 

receives due date data indicative of a date by which the a method for resolving recipient names in the background, 

follow-up action is to be performed and stores the due date It is a further object of the present invention to simplify 

data as one of the plurality of properties. the process of resolving ambiguous names and to automati- 

The present invention also provides a method for display- cally create nicknames based on how the ambiguous names 

ing the status of a follow-up action associated with the are resolved. 

message item. The method includes receiving a message It is a further object of the present invention to provide a 

item that includes a status property associated with the method for specifying a follow-up action and due date 

follow-up action and determining whether the message item associated with a message item. 

includes the status property. If so, the data associated with It is a further object of the present invention to assist the 

the status property is received and is displayed in conjunc- user in managing e-mail messages that include specific 

tion with the message item. follow-up actions. 

More particularly described, the present invention pro- It is a fiuther object of the present invention to allow 

vides an improved message item for transmission in an 45 e-mail users to create custom e-mail forms and easily share 

electronic mail system. The message item includes a mes- the custom forms with other users, 

sage flag property and a status property. The message flag It is a further object of the present invention to provide a 

property is indicative of a follow-up action associated with method for soliciting input from a group of e-mail recipients 

the message item. The status properly includes status data and automatically tallying their responses, 

indicative of whether the follow-up action has been com- 50 These and other objects, features, and advantages of the 

pie ted by a recipient of the message item. present invention may be more clearly understood and 

In yet another aspect, the present invention provides a appreciated from a review of the following detailed descrip- 

method for transmitting custom form data as part of a tion of the disclosed embodiments and by reference to the 

message item. Custom form data is obtained. The custom appended drawings and claims, 

form data indicates the layout of a custom form comprising 55 ^^^^^ DESCRIPITON OF THE DRAWINGS 
a plurality of fields for displaymg field data. The custom 

form data is stored as one of a pliu-ality of properties f^G. 1 is a block diagram of a personal computer that 

associated with the message item. Once the message is provides the operating environment for the preferred 

composed, the message item, including the form property, is embodiment of the present invention, 

transmitted to the recipient. 60 I^G. 2 is a block diagram illustrating the interface 

The present invention also provides a method for receiv- between a computer's input/output devices, an operating 

ing a message item that includes custom form data and system, and an application program, 

displaying the message item in a custom form. A message FIG. 3 is a diagram illustrating the modular architecture 

item, which includes a plurality of properties, is received. defined by the Messaging Application Programming Inter- 

The method includes determining whether the message item 65 face (MAPI). 

includes a form property. If the message item includes a FIG. 4 is a diagram illustrating the hierarchical arrange- 

form property, the custom form data that is stored in the form ment of a MAPI message store. 
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FIG. 5 is a diagram illustrating the MAPI form architec- 
ture, 

FIG. 6, consisting of FIGS, 6a-c, illustrates the principal 
user interface provided by an automatic name checking 
feature of the preferred embodiment of the present inven- 5 
tion. 

FIG. 7, consisting of FIGS. 7a-c, illustrates the user 
interface associated with the process of resolving nicknames 
in accordance with the preferred embodiment of the present 
invention. 

FIG. 8 is a flow diagram illustrating the preferred method 
for resolving e-mail addresses, as performed by the user. 

FIG. 9 is a flow diagram illustrating the preferred method 
for resolving e-mail addresses, as performed by the com- 
puter. 

FIG. 10 is a state diagram illustrating the preferred 
method for resolving nicknames, as performed by the com- 
puter. 

FIG. 11 is a diagram illustrating the data properties that 
constitute an e-mail message item including a message flag. 

FIG. 12 is a flow diagram illustrating the preferred 
method for adding a message flag to an e-mail message, as 
performed by a user. 

FIG. 13 is a state diagram iUustrating the preferred 25 
method for adding a message flag to an e-mail item, as 
performed by a computer, 

FIG. 14 is an illustration of a screen display containing a 
list view of the messages in a user's inbox in accordance 
with the preferred embodiment of the present invention. 30 

FIG. 15 is an illustration of a screen display of a message 
view of an e-mail message including a message flag in 
accordance with the preferred embodiment of the present 
invention. 

FIG. 16 is a flow diagram illustrating the preferred 35 
method for reviewing and editing an e-mail message, as 
performed by the user. 

FIG. 17 is a state diagram illustrating the preferred 
method for reviewing and editing an e-mail message, as 
performed by a computer. 40 

FIG. 18 is a flow diagram illustrating the preferred 
method for generating reminders and past due indicia asso- 
ciated with e-mafl messages that include message flags. 

FIG. 19 is a diagram illustrating the data properties that 
constitute an e-mail item that uses a custom form in accor- 
dance with the preferred embodiment of the present inven- 
tion. 

FIG, 20 is a flow diagram illustrating the preferred 
method for creating and sending an e-mafl message that uses 
a custom form, as performed by a user. 

FIG. 21 is an illustration of a field chooser dialog box in 
accordance with the preferred embodiment of the present 
invention, 

FIG. 22 is a state diagram iUustrating the preferred 
method for creating and sending an e-mafl message that uses 
a custom form, as performed by the computer. 

FIG. 23 is an example of a screen display that is displayed 
to the sender of an e-mail message that uses a custom form 
in accordance with the preferred embodiment of the present go 
invention. 

FIG. 24 is a flow diagram fllustrating the preferred 
method for receiving and displaying an e-mafl message with 
a custom form, as performed by the computer. 

FIG. 25 is a representative example of a screen display of 65 
a "read" page that is displayed to the recipient of an e-mail 
message that uses a custom form. 
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FIG. 26 is a diagram illustrating the data properties that 
constitute an autoresponse e-mail message item in accor- 
dance with the preferred embodiment of the present inven- 
tion. 

FIG. 27 is a flow diagram iUustrating the preferred 
method for creating and sending an autoresponse message, 
as performed by a user. 

FIG. 28 is an illustration of a screen display of an options 
page for selecting an autoresponse message. 

FIG. 29 is a state diagram illustrating the preferred 
method for creating and sending an autoresponse message, 
as performed by the computer. 

FIG. 30 is a flow diagram of the steps performed in 
replying to an autoresponse message, as performed by a 
user. 

FIG. 31 is a representative example of a screen display of 
a recipient's view of an autoresponse message. 

FIG. 32 is a state diagram illustrating the preferred 
method for opening an autoresponse message and sending a 
reply to an autoresponse message, as performed by the 
computer. 

FIG. 33 is a flow diagram iUustrating the steps carried out 
in the background to process an autoresponse reply message. 

FIG. 34 is a state diagram iUustrating the preferred 
method for updating the sent mail copy of an autoresponse 
message, as performed by the computer. 

FIG. 35 is an example of a screen display of an inbox of 
the sender of an autoresponse message in accordance with 
the preferred embodiment of the present invention. 

FIG. 36 is an example of a screen display of the sent mail 
copy of an autoresponse message in accordance with the 
preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The present invention is directed to features associated 
with an electronic mafl (e-mail) program module. The 
preferred embodiment of the present invention is repre- 
sented by the "MICROSOFT OUTLOOK" program, which 
is a workgroup personal information management program 
published by Microsoft Corporation of Redmond, Washing- 
ton. Briefly described, the preferred program allows users to 
manage their own calendar, messages, tasks, notes, and 
contacts and to share this information with others. Like 
many personal information managers, the preferred appH- 
cation program is divided into several modules, including a 
calendar manager, a task list manager, a contact manager, a 
message manager (e-maU), and a notes manager. *~" 

Although the preferred embodiment wfll be generaUy 
described in the context of a program and an operating 
system running on a personal computer, those skflled in the 
art will recognize that the present invention also can be 
implemented in conjunction with other program modules for 
other types of computers. Furthermore, those skflled in the 
art wiU recognize that the present invention may be imple- 
mented in a stand-alone or in a distributed computing 
environment. In a distributed computing environment, pro- 
gram modules may be physicaUy located in different local 
and remote memory storage devices. Execution of the pro- 
gram modules may occur locally in a stand-alone manner or 
remotely in a client/server manner. Examples of such dis- 
tributed computing environments include local area net- 
works of an oflSce, enterprise -wide computer networks, and 
the global Internet. 

The detailed description which foUows is represented 
largely in terms of processes and symbolic representations 



11/06/2002, EAST Version: 1.03.0007 



5,923,848 

9 10 

of Operations by conventional computer components, designed to operate. Those skilled in the art will immedi- 
including a central processing unit (CPU), memory storage ately appreciate that FIGS. 1-5 and the associated discus- 
devices for the CPU, display devices, and input devices. sion are intended to provide a brief, general description of 
Furthermore, these processes and operations may utilize the preferred computer hardware and program modules, and 
conventional computer components in a heterogeneous dis- 5 that additional information is readily available in the appro- 
tributed computing environment, including remote file pr^^te programming manuals, user's guides, and similar 
servers, remote compute servers, and remote memory stor- publications, 
age devices. Each of these conventional distributed comput- 
ing components is accessible by the CPU via a communi- The Computer Hardware 

cations network. in ^ . , 1 

™_ , . _rju.u . FIG. 1 dlustrates a conventional personal computer 10 

-nie processes and operations performed by the computer ^^.^^^j^ supporting the operation of the preferred 

mclude the manipulation or signals by a CPU or remote . . r fi: * • a u • ciy- t 

^ . f , , . J embodiment of the present invention. As shown in rIG. 1, 

server and the maintenance of these signals within data , : m * * * 1 j • 

. , , . £ . , , the personal computer 10 operates in a networked environ- 

structures resident m one or more of the local or remote . .1^ ^ • i *• . . * 11 ^n. 

, . c< u J . . ^ • ment with logical connections to a remote computer 11. The 

memory storage devices. Such data structures unpose a 15 , . , * , , 1 „ m ^ 

. . ^. . r J . . J logical cormections between the personal computer 10 and 

physical organization upon the collection of data stored * , . n * a u ^ ^ 

^ ^ , ^ , . , the remote computer 11 are represented by a local area 

within a memory storage device and represent specific . i j . ii-inn, c r 

, , . . .-1 . L 1- network 12 and a wide area network 13. Those of ordinary 

electrical or magnetic elements. These symboUc represen- , 1, • n • *u * *u- v w 

. ^ J u 1 -11 J • ^ r skill in the art will recognize that in this cUent/server 

tations are the means used by those skilled in the art of ^ *u . * n a *• 

J , * *■ . * configuration, the remote computer 11 may function as a file 

computer programming and computer construction to most 20 * 

™, V 1 . J J- • . server or compute server, 

effectively convey teachings and discoveries to others ^ 

skilled in the art personal computer 10 includes a central processing 
For the purposes of this discussion, a process is geaeraUy ""i' (^PU) 14. such as the 80486 or "PENTIUM" micro- 
conceived to be a sequence of computer-executed steps processors manufactured by Intel Corporation of Santa 
leading to a desired result. These steps generally require 25 ^^'^'.^^ personal computer also includes system 
physical manipulations of physical quantities. Usually, ""^^^ (including read only memory (ROM) 16 and 
though not necessarily, these quantities take the form of "^""^ i?' ""^f^ "s connected to 
electrical, magnetic, or optical signals capable of being ^t^y a system bus 18. llie preferred computer 10 
stored, transferred, combined, compared^ or otherwise '^.^ BIOS 19 which « stored m ROM 16. Those 
manipulated. It is conventional for those skilled in the art to 30 ^"^"^^ art will recognize that the BIOS 19 is a set of 
refer to these signals as bits, bytes, words, data, objects. ^f'" 'h^' h^^P^ '° ''^"^f" ""Z"™"'"" 
properties, flags, types, identifiers, values, elements. elements wthm the personal computer 10. Those skiUed m 
symbols, characters, terms, numbers, points, records. l''^ f ' appreciate that the present invention may be 
images, files or the like. It should be kept in mind, however. "nplemented on computers havmg other architectures, such 
that these and similar terms should be associated with 35 as computers that do not use a BIOS and tho^^ 
appropriate physical quantities for computer operations, and other microprcH:essors, such as Uie MIPS or POWER 
that these terms are merely conventional labels applied to ^ ^'''f^^ °^ microprocessors from Sihoon Graphics and 
physical quantities that exist within and during operation of Motorola, respectively. 

the computer. Within the personal computer 10, a local hard disk drive 

It should also be understood that manipulations within the 40 20 is connected to the system bus 18 via a hard disk drive 

computer are often referred to in terms such as adding, '"'Efface 21. A floppy disk drive 22, which is used to read or 

comparing, receiving, sending, transmitting, replying, eto. ^'"'e a floppy disk 23, is connected to the system bus 18 via 

which are often associated with manual operations per- a floppy disk drive mterface 24. A CD-ROM drive 25, which 

formed by a human operator. The operations described '° '^^d a CD-ROM disk 26. is connected to the 

herein are machine operations performed in conjunction 45 system bus 18 via a CD-ROM mterface 27. A user enters 

with various input provided by a human operator or user that commands and mfomaation mto the personal computer 10 

interacts with the computer. "*'"8 devices, such as a keyboard 28 and/or 

In addition, it should be understood that the programs. P°'°''"g device such as a mouse 29, which are connected to 

processes, methods, etc. described herein are not related or "jf ^y*'*"" a serial port interface 30. Other types 

limited to any particular computer or apparatus, nor are they 50 °f PO>f "6 devices (not showt, m FIG. 1) include track pads, 

related or limited to any particular communication network f '^l' ^^^'^ g'"^^^ ""'^ 

architecture. Rather, various types of general purpose ''^^'^^^ positionmg a cursor on a computer 

machines may be used with program modules constructed in !°°'^'°' ^l. The momtor 31 or other kind of display device 

accordance with the teachings described herein. Similarly, it comiected to the system bus 18 via a video adapter 32. 

may prove advantageous to construct a specialized apparaUis S5 The remote computer 11 m this networked envuronmenl is 

to perform the method steps described herein by way of connected to a remote memory storage device 33. This 

dedicated computer systems in a specific network architec- remote memory storage device 33 is typicaUy a large capac- 

ture with hardwired logic or programs stored in nonvolatile 'tV device such as a hard disk drive, CD-ROM drive, 

memory, such as read only memory. magneto-optical drive or the like. The personal computer 10 

Referring now to the drawings, in which like numerals ^ connected to the remote computer 11 by a network 

represent like elements throughout the several figures, '"'"f'"* 34 which is used to communicate over the local 

aspects of the present invention and the preferred operating network 12. 

environment will be described. ^ shown in FIG. 1, the personal computer 10 is also 

connected to the remote computer 11 by a modem 35, which 

The Operating Environment ^ communicate over the wide area network 13, such 

FIGS. 1-5 illustrate various aspects of the preferred as the Internet. The modem 35 is connected to the system 

computing environment in which the present invention is bus 18 via the serial port interface 30. The modem 35 also 
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can be connected to the public switched telephone network "WINDOWS 3.1" operating system, IBM Corporation's 

(PSTN) or community antenna television (CATV) network. "OS/2" operating system, and the operating system used in 

Although illustrated in FIG. 1 as external to the personal "MACINTOSH" computers manufactured by Apple 

computer 10, those of ordinary skill in the art will quickly Computer, Inc. 

recognize that the modem 35 may also be internal to the 5^ The operating system 36 provides a variety of functions or 

personal computer 11, thus communicating directly via the services that allow an application program 37fl to easily deal 

system bus 18, It is important to note that connection to the vvith various types of input/output (UO). This allows the 

remote computer 11 via both the local area network 12 and application program 37a to issue relatively simple function 

the wide area network 13 is not required, but merely calls that cause the operating system 36 to perform the steps 
illustrates alternative methods of providing a communica- lo required to accomplish various tasks, such as displaying text 

tion path between the personal computer 10 and the remote on the monitor 31 (FIG. 1) or printing text on an attached 

computer 11. printer (not shown). Generally described (with reference to 

Although other internal components of the personal com- FIG. 2), the application program 37a communicates with the 

puter 10 are not shown, those of ordinary skill in the art will operating system 36 by calling predefined functions pro- 
appreciate that such components and the interconnection ^5 vided by the operating system 36. 'Ilie operating system 36 

between them are well known. Accordingly, additional responds by providing the requested information in a mes- 

details concerning the internal construction of the personal sage or by executing the requested task, 
computer 10 need not be disclosed in connection with the p^om this brief description, it should be appreciated that 

present invention. operating systems, such as the "WINDOWS 95" and "WIN- 

Those skilled in the art will understand that program DOWS NT" operating system, are quite complex and pro- 

modules such as an operating system 36, application pro- vide a wide variety of services that allow users and programs 

grams 37, and data are provided to the personal computer 10 to utilize the resources available in the personal computer, 

via computer- re ad able media. In the preferred computer, the Those skilled in the art will be familiar with operating 

computer-readable media include the local or remote systems and their various features, which include, but are in 

memory storage devices, which may include the local hard no means limited to, the specific messages and functions 

disk drive 20, floppy disk 23, CD-ROM 26, RAM 17, ROM described above. For more comprehensive information 

16, and the remote memory storage device 33. In the regarding the "WINDOWS 95" and "WINDOWS NT" 

preferred personal computer 10, the local hard disk drive 20 operating system and its interaction with programs, the 

is used to store data and programs, including the operating reader may refer to any of a variety of publications, includ- 

system and programs. ing the "Win32 Programmer's Reference" published by 

Microsoft Press and "Advanced Windows" published by 

The Operating System Microsoft Press. 

• HG. 2 is a simpUfied block diagram iUi^tratmg the Hie MAPI Messaging Architecture 

interaction between the computer hardware 200, the pre- 35 * * 

ferredoperatingsystem36, and an application program 37fl. ^ In the context of the present invention, the primary 7 
Referring now to both FIGS. 1 and 2, when the personal interaction between the preferred program and the operating 
computer 10 is turned on or reset, the Basic Input/Output system involves messaging related tasks. The preferred 
System (BIOS) 19, which is stored in the ROM 16, insfmcts operating system incorporates the Messaging Application 
the CPU 14 to load the operating system 36 from the hard Programming Interface (MAPI). The MAPI architecture is 
di sk drive 20 into the RAM I?. Once the opiatin g s ystem designed to make it easy for programmers to write 
36",isUa aded "into RAM~12 ,J(Iifc- CPU 1 4-£ xecutes the messaging-enabled applications that are independent of the 
operating svste m 36 ^nd causes the visual elements assoc i- underlying messaging system. MAPI provides high-level 
ated with the user inte rface of the operating sy stem 36 to be function thai can be used to implement sophisticated mes- 
displayed on the monitor ^1. 45 saging features with a relatively small amount of code. The 

code deals only with functions for sending, jscdaBg ^ and 
ad dressing message s. The underlying na gssaguig system is 
completely transpaTent. MAPI also provides pther message- 
related functionality, such as access to address books. — 
50 FIG. 3 illustrates the modular architecture defined by 
MAPI, ITie client applications 300 are application programs 
that take advantage of the MAPI subsystem 305. Client 
applications 300 implement messaging tasks as either their 



^ The operating system 36, in conjunction with the BIOS 19 
(FIG. 1) and associated device drivers, provides the basic 
interface between the computer's resources, the user, and the 
appli cation program 37fl. The operating system 36 i nterprets 
an d carries out instructions issued by the use r. For example, 
when the user wants to load an application program 37a, the 
operating system 36 interprets the instruction (e.g., double 
clicking on the application program's icon) and causes the 
CPU 14 to load the program code into RAM 17 from either 
the local hard disk drive 20, floppy disk 23, CD-ROM 26, or 



primary or secon dary focus. Mess^ging-based clien t 

,55 ap pUcaTit)ns:~stIcli7as applications tEaT send and rec eive 

the remote memory storage device 33. Once the application I el ectronic n iail^implement messaging tasks as ttieir primary 

program 37fl is loaded into the RAM 17, it is executed by the I focus.^POlTnon-messaging chent applications, which are 

CPU 14. In case of large programs, the CPU 14 loads | referred to as being "messaging-enabled" or "messaging- 

various portions of program modules into RAM 17 as/ aware," it is a secondary feature. 

needed. -J 50 The MAPI subsystem is made up of the MAPI spooler 
As discussed earlier, the preferred embodiment of the 310, a common user interface (not shown), and the pro- 
present invention is embodied in the "MICROSOFT OUT- gramming interfaces 315. The MAPI spooler is a separate 
LOOK" program, which is designed to operate in conjunc- interface that is responsible for sending messages to arid 
tion with Microsoft Corporation's "WINDOWS 95" or receiving messages from a messa^ nf^ system. The common 
"WINDOWS NT* operating systems. However, it should be 65 user interface is a set of dialog boxes that gives client 
understood that the invention can readily be implemented in applications a consistent look and users a consistent way to 
other operating systems, such as Microsoft Corporation's perform tasks. 



J 
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The prograrnming interfaces 315 are used by the MAPI 
subsystem 305 , by client applications 300, and by service 
provider writers. The main programming interface is an 
object-based interface known as the MAPI programming 
interface, which is based on the OLE Component Object 
Model. Client applications may also utilize any of three 
other interfaces, including simple MAPI, Common Messag- 
ing Calls (CMC) and the OLE Messaging Library, which are 
primarily for messaging-enabled and messaging-aware cli- \ 
ent applications. ■ — \ 

The MAPI spooler 310 is a separate process within the 
MAP I siibs yst cm 30L .ai ad. is responsible for sending me s- 
sages"to and receiving mess ag e, from a -c nessaging sy stem 
320r-Tlie spooler runs as a background process and also 



Client applications 300 communicate with the transport 
providers 340 through a message store provider 330. When 
an incoming message is detected, the transport provider 
informs the MAPI spooler and the message is delivered to 
the appropriate message store. To handle outgoing 
messages, the message store moves the message to the 
outbound queue, informs the MAPI spooler, and the spooler 
transfers it to the appropriate transport providers. 

The operation of these MAPI components is illustrated by ■ 
describing the flow of an e-mail message through these 
components. IT ie user of a client application 300 sends^ 
me5vsap; e tn one or more recipiejife . A message store provider 
330 initiates the sending process and formats the message 
with additional information needed for transmission. The 
MAPI spooler 310 receives the message, performs any 



performs several funct ions related to jn gssagin g distribution. 15 required preprocessing, and delivers it to the appropriate 



ThosG include informing a client application when a new 
message has been delivered, invoking message preprocess- 
ing and post processing, generating r eports that indicate that 
message delivery has occurred, and maintaining sta tus on 
processed recipients. 

The MAPI service providers 325 are -located between 
MAPI subsystem 305 and the messaging systems 320. 
Service providers are drivers that connect MAPI client 
applications 300 to an underlying messaging system 32Q. 
Most messaging systems include three types of service 
providers: message store providers 330, address book or 
directory providers 335, and message transport providers 
340. TTie service providers work with MAPI to create and. 



send messages in the following way. Messages are created 
using a form that is appropriate for the specific type, or class; 
of message. The completed message is addressed to one or 
more recipients. Wh en the client sends the message, the 
messae rq stnr^ prov ider 3!3ri checks inat each recipie nt has a 
unique 



transport provider 340. The transport provider 340 gives the 
message to its messaging system 320, which sends it to the 
intended recipient(s). When a message is received, the 
transport provider 340 receives a message from its messag- 
20 ing system 320 and notifies the MAPI spooler 310. The 
spooler 310 performs any necessary post processing and 
informs the message store provider 330 that a new message 
has arrived. The notification causes the client application 
300 to refresh its message display, which enables the user to 
25 read the new message. 

Client application users 9a access a summary view of the 
messaps contained with each folder o r view them individu- 
A^ally with a torm. Whether the client aisplays a standard form 
y supplied by MAPI or a customer form supplied by a form 



riTTi^^pcs and that tnc message nas an oTTIie 



30 developer depends on the type, or class, of the message. In 
FIG. 4, the first folder 400 contains note messages and uses 
the MAPI standard note form. The second folder 405 
contains inventory request messages and uses a custom 
inventory form. The information on both forms represents 
35 the properties, or attributes, of the message. Messages are 
the units of data transferred from one user to another. Every 
message contains some text, which is formatted simply or 
more intricately depending on the form that is used, and 
envelope information that is used for transmission. 
40t^ A MAPI property is an attribute of a MAPI object, and' 
Address book providers 335 handle access to directory-, ^escribes something about the object, such as the subject 

fine of a message of the address type nf a Hi^^^phntinri h'st 



i nformation necessary fox transmission. If, there is a question 
a6but a recipient, such as can occur when there are multiple 
recipients with the same name, an address book provider 
resolves the ambiguity, llie message in then placed in the 
outbound queue. 



information. Depending on the type of recipient and the 
address book provider, there is a wide range of information 
that can be made available. For example, all address book 
pr oviders 335 s|ore a recipient's name, address, and _address 
typ e and or^anize the data using one or more contain ers. 
MAPI integrates all the information supplied by the installed 
address book providers into a single address book, thereby 
presenting a unified view to the client application. The users 
of client applications can view the contents of address book 
containers and in some cases modify it. MA PI's Persona l 
Address Book i s an example of a modifiabt^Tddress b ook 
cofltalB exthat allo ws new entriesjo be added^ ndje^iiting 
entries-tQJ be ipqdified or^eleted . 

Message store providers 330 handle the storage and*>5 
retrieval of messages and other information for the users of f 
client application. As illustrated in FIG. 4, the message \ 
information is orpanig ^d using a hierarchical system known 



Every MAPI property has a value, a type, a nd an identifier. 



as a message store, which is implemented in multiple levels, 
with containers called folders holding messages of different 
types. There is no limit to the number of levels in a message 
store, and folders can contain many sub-folders. 

Transport providers 340 handle message transmission and 
reception. They control the interaction between the MAPI 
spooler 310 and the underlying messaging system 320. They 
also implement security if necessary and take care of any 
pre-processing and post -processing tasks that are required^ 



The value is the descriptive data, such as the text in a 
45 message body. The type describes the kind of data, such as 
a string, numeric, or Boolean. The identifier is the number 
that uniquely describes the property. The identifier and type 
are combined to form a "property tag," which is a constant 
that can be used to easily refer to the property. Property tags 
50 share a common format, they begin with the prefix "PR" and 
are made up of one or more words that describe the property. 
For example, PR_MESSAGE_BODY is the tag for the 
message body property. The property tag and value arc 
stored_together in system, memor y 15 (FIG. 1) as a single 
data structure. 

MAPI also employs "profiles," which are collections of 
information about the message services and service provid- 
ers that a user of a client application 300 wants to be 
available during a particular MAPI session. Every user has 
at least one profile. Multiple profiles may be used in some 
cases. For example, a user might have one profile to work 
with a server-based message store service and another 
profile to work with a message store service on the local 
computer. A user may have profiles on more than one 
65 computer. Similarly, a computer may store profiles for more 
than one user. Profiles provide a flexible way to select 
combinations of message systems. 
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In the MAPI environment, a form is a viewer for a 
noessage. Each message has a message class that determines 
the particular form that is used as its viewer. MAPI defines 
a few messages classes and has implemented the forms for 
viewing these messages. Client application developers can 
create new message classes and custom forms for viewing 
messages with the new classes. 

Every custom form implements a set of standard menu 
commands (e.g., open, create, delete, and reply) and a set of 
commands that are specific to that particular form. These 
commands are also referred to as "verbs." FIG. 5 illustrates 
the MAPI form architecture, which involves three main 
components: a form registry provider 500, a form server 
505, and a form viewer 510. 

The form registry provider 500 maintains a library of^^ 
information about all of the forms available on the computer 
and enables the client to select a form that is suitable for the 
message being displayed. Form data is stored in a form 
registry 502, which is stored in one of the computer's 
memory storage devices. The form server 505 is responsible 
for displaying the form and providing the information for the 
display. The form server manages the user's interaction with 
the form by interpreting the menu selections and processing 
the messages. The form viewer 510 is a component within 
a client application that contains the display and presents it 
to the user ^ 

From the foregoing, it will be appreciated that MAPI 
provides a wide variety of features and functions in addition 
to those included in the brief description presented above. 
For additional information regarding MAPI, the reader may 
refer to the MAPI documentation, entitled Messaging Appli- 
cation Programming Interface (MAPI) version 1.0, which is 
published by Microsoft Corporation, and which is incorpo:^ 
rated herein by reference. 

^J^^ The Preferred Application Program 



As mentioned above, the preferred embodiment of the 
present invention is represented by the "MICROSOFT OUT- 
LOOK" workgroup personal information manager, which is 
published by Microsoft Corporation. The preferred client 
application is divided into several modules, including a 
calendar manager, a task Ust manager, a contact manager, a 
message manager (e-mail), and a notes manager. In the 
preferred client application, integration between the mod- 
ules is both simple and extensive because all information is 
stored in a MAPI data store, which is an extensible, object- 
orie nted database . The preferred application program incor- 
porates the^atures of MAPI version 1.0. J 
All folders (containers) contain objects, or items. In the 
^ preferred application program, there are a variety of kinds of 
items: e-mail items, appointment items, task items, address 
items, etc. Items have a set of fields and a behavior associ- 
ated with them. For example, an e-mail item has To, From, 
CC, Subject, date and time fields among others. The behav- 
ior of e-mail items includes knowledge of what it means to 
Forwa rd or Reply/Reply All . 

Fields are atomic units of data such as the subject and 
received date of a message. In most cases, a field belongs to 
an item. Afield is distinct from a "property," which refers to 
an underlying atomic unit of data at the object storage level, 
e.g. in a MAPI message. Fields map to properties, but the 
mapping is not necessarily one-to-one. 

A user stores information in the form of items. Items, in 
^ turn, reside in folders. A message is a collection of proper- 
ties. Items are com posed of fields. For example, the "sub- 
ject" in an e-mail note would be a field called "subject" in 



the e-mail item. I n a MAPI store, objects (messages'^ have a 
simil ar structure^ jxcent they arc com]^os^of propcrtks . In 
most cases, a field maps directry to a MAPI property. 
However, there can actually be a many-to-many mapping 
between fields and the MAPI properties in which they are 
stored. 

In the preferred application program, every item is 'ini- 
tially created from a template. A template is the "mold" firom 
which new items are made and as such describes the fields 
and the item-the data types, default values, formatting rules, 
etc. For example, there would be a default template for each 
kind of item listed above: appointments, to-do items, notes, 
e-mail messages, etc. 

The fields in an item may be different than the fields in the 
template it came from, because items can have custom fields 
which other instances of the templates do not have. An item 
always has a template associated with it, however, even if it 
has so many custom fields that it bears little resemblance to 
the original templates. 

The user creates a template by creating an item, custom- 
izing it by adding or deleting fields as necessary, setting 
initial values for fields and then saving it, giving the tem- 
plate a name. 'ITie user can either create a new template (by 
giving it a new name) or replace the existing one. One way 
this would be used is to make a template out of an item 
which has one or more custom fields; if the user thinks that 
^an item with that set of fields is useful for more than one or 
two items, this allows an easy way to do so. 

From this brief description, those skilled in the art will 
appreciate that the preferred application program provides a 
wide variety of features and functions in addition to those 
included in the brief description presented above. For addi- 
tional information regarding the "MICROSOFT OUT- 
LOOK" application program, the reader may refer to the 
documentation that is distributed with the program. 
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\, ^hen aPL eimail user composes an e-mail message , the 
user identifies the recipient(s) of the message by entering 
one or more display names in the message" s address field. 
Before the message can actually be transmitted by the e-mail 
system, the system must match each display name entered in 
the address field to the specific e-mail address (or address 
book entry) of a registered user. The e-mail addresses of all 
registered users are referred to as aliases, and are maintained 
in a system directory. The directory may cross reference 
each alias to other information about the user, such as first 
and last name, department, office location, and phone num- 
ber. The process of matching the display name(s) to an 
e-mail address or alias is referred to as "resolving" the 
names. - 

In most e-mail systems, the display names are resolved 
when the user attempts to send the message, or when the user 
invokes a "check names" command. In either case, the 
e-mail program resolves unambiguous display names with- 
out requiring any additional input from the user. In order to 
resolve ambiguous display names, the e-mail program dis- 
plays a dialog box that allows the user to select the intended 
recipient from a list of possible matches. 

The present invention provides a method for resolving 
names in the background, which means that the user may 
continue to use the computer to perform other tasks while 
the display names are being resolved. In the preferred 
program, the display names are typically resolved while the 
user is composing the remainder of the e-mail message. The 
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present invention also provides an improved system for 
resolving ambiguous names. The present invention auto- 
matically remembers how ambiguous names are resolved 
the first time they are encountered and uses that information 
to resolve those names in the future. 

HGS. 6 and 7 illustrate the user interface that is employed 
by the preferred embodiment of the present invention. FIGS. 
6fl-6c illustrate a process for resolving names in accordance 
with the preferred embodiment of the present invention. 
FIGS, la-lc illustrate the operation of the preferred auto- 
malic nickname resolution feature. 

FIG. 6a illustrates an address field 600 of an e-mail form 
that is being used to compose a message item. The form and 
address field 600 are displayed on the monitor 31 (FIG. 1). 
At this point, the user has typed in three display names, 
which provide identifying information about each of the 
intended recipients. The entered display name may include 
all or part of the intended recipient's first name, last name, 
and/or e-mail alias. Each display name is preferably sepa- 
rated by an appropriate delimiter, such as a semicolon. 

As soon as the user moves the cursor to another field on 
the e-mail form, the e-mail program module begins to 
resolve the recipient names in the background, while the 
user continues to compose the remainder of the message. As 
mentioned above, "resolving" the names means attempting 
to match the display names in the address field to specific 
user aliases that are included in a centralized address book 
or directory, which is typically stored on a remote server, 
such as remote memory storage device 33 (FIG. 1). In the 
preferred application program, the e-mail system searches 
several address book fields in an effort to match the display 
names with the first name, last name, and/or alias of a 
registered user. Thus, in this example, the e-mail program 
will attempt to match "billb," "sm henry," and "palterson" 
with specific address book entries belonging to registered 
users. 

HG. 66 illustrates the results of the effort to resolve the 
names. If a display name is unambiguous and matches only 
one registered user, the name of that user is inserted in the 
address field. If the display name is ambiguous, the e-mail 
program indicates that the display name needs to be manu- 
ally resolved by displaying the display name and a prede- 
termined indicia, such as a squiggly line 605 beneath the 
display name. FIG. 6/> indicates that the display names "sm 
henry" and "patterson" were unambiguously matched to 
"Henry Smith" and "Roger Patterson," respectively. Names 
that are unambiguoiisly matched appear with a regular 
underline beneath the display name. The squiggly line 
beneath the display name "billb" indicates that the e-mail 
system was unable to find a unique match for that display 
name. 

FIG. 6c illustrates the process by which a user manually 
resolves ambiguous names. In the preferred system, the user 
places the cursor over the unresolved display name and 
clicks the right mouse button. In response, the e-mail 
program displays a context menu 610 that includes a list of 
possible matches. In this case, the possible matches include 
users whose first name is Bill and whose last name begins 
with the letter "B." If the intended recipient's name is 
displayed in the context menu 610, the user may select the 
correct name from the list. 

If the intended recipient's name is not displayed in the 
context menu 610, the user may choose one of several 
options. For example, the "show more names" command in 
the context menu 610 indicates that there are more possible 
matches. If the user selects this command, a dialog will 
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display additional names from which the user may select. 
The "create new address for billb" option in the context 
menu 610 allows the user to create an entry in his or her 
personal address book. Those skilled in the art will appre- 

5 ciate that this is typically used to store addresses of e-mail 
recipients who are not registered users on the local e-mail 
system. For example, if "billb" is a firiend that the user 
communicates with via Internet e-mail, the user can record 
Bill's Internet e-mail address in his or her personal address 
book. The "address book" command in the context menu 
610 instructs the e-mail program to display the e-mail 
system's complete address book, from which the user may 
select the e-mail address of the intended recipient. 

In addition to the features described in conjunction with 
FIGS. 6fl-c, the preferred e-mail program module automati- 
cally creates a List of nicknames that are based on how the 
user resolves ambiguous display names. This allows a user 
to use convenient, but ambiguous, display names to identify 
intended recipients. For example, if the user frequently 
sends e-mail messages to Bill Bailey, he or she may prefer 
to use "billb" as a convenient nickname although it is 
ambiguous. In FIG. la, the user has entered "billb" in the 
address field 700. As before, the e-mail system will attempt 
to match "billb" to an e-mail aUas. However, an e-mail 

2^ system in accordance with the preferred embodiment will 
check a nicknames memory cache, which is stored in system 
memory 15 (FIG, 1), to see ff the user has manually resolved 
the ambiguous display name "billb" in the past. If so, the 
e-mail program will display the previous recipient's full 
name and indicia that indicates this is a nickname. In the 
preferred e-mail program, resolved nicknames are displayed 
with blue dashed lines beneath them. In this example, the 
dashed line 705 beneath "Bill Bailey'* indicates to the user 
that Bill Bailey is the user that is ciurently associated with 

35 the nickname "biUb" (FIG. lb). 

If Bill Bailey is the intended recipient, the user need not 
take any other action before sending the message. However, 
if the user intended to send the message to someone other 
than Bill Bailey, the user may override the nickname using 

4Q a context menu 710 (FIG. 7c). This process is identical to the 
process for resolving names described in conjunction with 
FIG. 6/)j except that the first name listed in the context menu 
710 is the name to which the nickname has been matched. 
If the user overrides the previous nickname, the "billb" name 

45 in the nicknames memory cache is redefined to correspond 
to the most recent intended recipient. Thus, a nickname 
appears only once in the nickname list and is overwritten as 
changes or corrections are made by the user, 

FIG. 8 is a flow diagram illustrating the preferred process 

50 800 by which a user enters and resolves display names. 
Those skilled in the art will appreciate that although the 
method 800 is described primarily in terms of steps carried 
out by a user, the present invention is a computer- 
implemented process that is carried out by a computer in 

55 response to input from the user and instructions provided by 
the preferred e-mail program module. 

The process 800 begins at start step 805 and proceeds to 
step 810 when the user selects the command that creates a 
new message. At step 815 the user enters display names that 

60 indicate the identity of the of the intended recipients. As 
mentioned earlier, the display names may include all or part 
of the recipient's first name, last name, or e-mail alias. At 
step 820 the user moves the cursor out of the address field 
600 (FIG, 6) and continues to compose the remainder of the 

65 message. 

At step 825 the user reviews the addresses that are 
displayed in the address field 600 (FIG. 6). At this point, the 
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e-mail system will have attempted to resolve the names in nickname list. As described above, the nickname list is 
the background and displayed the results in the address field. stored in a memory cache that is part of the user's profile, 
At step 830 the user determines whether any of the display and is used to automatically create nicknames. The nick- 
names need to be resolved manually. As mentioned above, name is stored with the actual e-mail alias or address book 
this will be the case for ambiguous display names, which are 5 entry of the intended recipient. If this is the first time a 
preferably displayed with a squiggly line beneath them, or nickname is resolved, it is added to the nickname cache. If 
for incorrectly resolved nicknames. If none of the display the nickname was earlier matched to a different alias, the 
names need to be resolved manually, the user goes to step nickname list is updated to reflect the current recipient. In 
835 and sends the e-mail message. From there, the method the preferred system, the nickname file is part of the user's 
terminates at step 840. profile, which is stored on one or more of the computer's 

If, at step 830, the user determines that one or more of the memory storage devices, 

display names needs to be manuaUy resolved, the user goes ^hen a user enters an Internet e-mail address in the fonn 

to step 845. At step 845 the user manually resolves the xxxxx@yyyyy.zzz, the user need not create a new name 

display naines usmg the context menu and other options ^ ^^^^^^^ before the name can be resolved, ^fhe 

described above m conjunction with FIGS. 6c and 7c. preferred e-mail system simply identifies such an address as 

FIG. 9 IS a flow diagram that illustrates the preferred an Internet address and resolves it without further user 

method 900 by which the computer attempts to resolve the intervention. 

display names entered in the address field. Although the j^^^ appreciate that in the preferred 

method 900 is described m terms of tasks earned out by a appUcation program, addresses are also resolved when the 

computer, those skiUed m the art will appreciate that the ^ser sends the message or if the user selects the "check 

present mvention is a computer-implemented process that is „ames" command. As such, the preferred embodiment is 

earned out by the computer m response to input from the implemented without requiring any changes to these fea- 

user and instructions provided by the preferred e-mail pro- ^^^ition, if the user sends the message or selects the 

gram mo u e. "check names" command while the e-mail program module 

The method 900 begins at start step 905 and proceeds to 35 is operating in the background, the processes or threads 

step 905 when the user moves the cursor out of the address associated with the e-mail program are automatically halted, 

field and to another field on the e-mail form. At step 910 the jn addition, if the user attempts to send the message without 

computer first checks to see if the display names in the resolving the ambiguous display names displayed by the 

address field corresponds to a nickname that is stored in the g.^ail program, the process defaults back to the normal 

nicknames memory cache, which IS stored in the computer's 3^ process for resolving names, which displays a dialog box 

memory storage devices as part of the user's profile. At step from which the user must choose the correct name. 

915 the computer determines whether any display names p^^^ ^ description of the various features, 

remam to be resolved, f all of the display names were those skilled in the art will appreciate that the name checking 

resolved by matchmg mcknames,th ^^^^^^^ ^^^^^^ ^ automaticaUy 

920 and displays the address data with the proper mdicia.^ 35 ,^3^1^,3 ^i 1 ^^^^3 ^^ile a user composes a message 

discussed above, m the case of nicknames, the fiiU name of ^^^^^^ ^^^^ ^^^^^^ ^^^^1^- ambiguous 

the recipient IS inserted m the address field and IS preferably L, /- „ u- 1 r 1 • *u 

tj -.uui ^uji- i_ U «X« names by providing multiple options for resolving the 

marked with a blue dashed line beneath it. From Step 920, „™u™, #- 1 it r r ^ 1 . 

, , , , \ww^ ambiguities. In addition, the preferred e-mail program auto- 

the computer proceeds to step 925 and the method 900 vTn ™* a ^ ■ . • i *f i 

. . matically creates and maintains a list of nicknames, 
termmates. 

If, at step 915 the computer determines that there are ^h^ Preferred Method for Providing Message Flags 

additional display names to resolve, the computer goes to E-mail messages typically fall into one of three catego- 

step 930 and attempts to resolve the remaining display ries: (1) those in which the recipient is asked or instmcted to 

names. In the preferred e-mail program, this is accomplished do something; (2) those which prompt the recipient to take 

by calling the appropriate MAPI functions, such as 45 some form of action though he or she is not explicitly 

MAPIResolveName. Those skilled in the art will appreciate requested by the sender to do so; and (3) information that 

that this MAPI function handles the addressing chore of requires no follow-up action. Generally, an e-mail recipient 

resolving informal names with actual e-mail aliases. From will read a message, decide what response is required and 

step 930 the computer proceeds to step 920 and displays the either act on that decision immediately or close the message 

address data with the proper indicia. As discussed above, the 50 and postpone the required action until later. Although a 

full name of unambiguous recipients is inserted in the recipient may know that some form of follow-up action is 

address field. Ambiguous addresses are preferably marked required, once the message is closed it is often easily 

with a squiggly line beneath them. From step 920, the overiooked or lost in the clutter of the other messages in the 

computer proceeds to step 925 and the method 900 termi- inbox. This is especially Hkely if the recipient receives a 

n^tcs. 55 large number of e-mail messages. 

HG, 10 is a simple state diagram that illustrates the The prior art has not provided any convenient or effective 

method 1000 by which the computer creates and maintains way for senders or recipients to flag messages that require 

the list of nicknames. This process has also been described follow-up action. An aspect of the present invention allows 

in conjunction with FIGS. 6 and 7. The method 1000 begins a user (sender or recipient) to attach a flag, or message flag, 

at the idle state 1005. At this point, the computer has 60 to an e-mail message, l^e message flag clearly identifies the 

displayed at least one ambiguous display name or nickname follow-up action (e.g., fax report), or action item, that is 

in the address field. When the user selects a nickname or an required to deal with the message, and may also include a 

ambiguous display name, the computer goes to state 1010 deadline. The message flag and deadline draw the recipient's 

and displays a context menu 610 (FIG. 6) that includes a list attention to the main action item associated with the mes- 

of possible matches (see FIGS. 6c and 7c). 55 sage. 

When the user selects one of the names from the context Message flags make it easier for the recipient of e-mail 

menu, the computer goes to state 1015 and updates the messages to organize and manage his or her inbox. With 
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message flagging, an e-mail recipient may work through his 
or her inbox and flag messages that require some form of 
follow-up action. Once the foUow-up action is complete, the 
recipient may mark the message to so indicate the completed 
state. If an item is flagged with a deadline and has not been 
marked as complete, the e-mail program will provide an 
alarm at a predetermined period of time prior to the deadline. 
Similarly, if an item is marked with a deadline that arrives 
before the item is marked as complete, the e-mail program 
will change the display attributes of the overdue item, thus 
making it readily apparent to the recipient. The messages 
may also be sorted or grouped according to whether they 
include message flags, by deadline, or by whether they are 
marked as completed. These features allow the user to 
effectively manage the tasks that result from incoming 
e-mail messages. 

Turning now to FIGS. 11-18, the preferred method for 
providing message flags wiU now be described. As discussed 
above, the message flagging features form a part of the 
preferred application program, which is the "MICROSOFT 
OUTLOOK" personal information manager, published by 
Microsoft Corporation. The preferred application program 
includes a variety of program modules that are tailored to 
various tasks, including scheduling, electronic mail, task 
management ("to-do" lists), and contact management. This 
aspect of the present invention deals primarily with the 
features of the e-mail program module. 

FIG, 11 illustrates the preferred data structure in which 
data is stored in an e-mail message. Generally, an e-mail 
message (also referred to as an e-mail item) includes a 
plurality of properties. Each property is associated with data 
that represents the value of that property. In most cases, the 
properties correspond to a field that is displayed by the 
e-mail program module. For example, most e-mail items 
include the following properties, which correspond to fields 
displayed on the e-mail form, as shown in Table I. 

TABLE I 



Property Tag 


\^lue (data) 


Sender 


The name of the user that 




originated the e-mail item 


Recipients(s) 


The name of the 




recipient(s) of the e-mail 




item 


Subject 


The subject of the e-mail 




message 


Body 


the text of the e-mail 




message 



A user composes an e-mail message by entering values in 
displayed fields that correspond to the properties. ITiose 
skilled in the art will appreciate that most e-mail modules 
automatically insert the name of the sender in the sender 
field. When an e-mail message is transmitted to a recipient, 
its constituent properties and their associated values are 
transmitted to the recipient via a network. 

As illustrated in FIG. 11, the preferred e-mail module uses 
three additional properties to provide the message flag 
features. The additional properties include status 1100, mes- 
sage flag 1105, and due date 1110 properties. Each property 
consists of the property tag and the associated value. The 
status property llOO indicates one of three states: (1) there 
is no flag associated with the message; (2) the e-mail item 
includes a message flag and is not complete; and (3) the 
e-mail item includes a message flag and is complete. The 
message flag property 1105 indicates the action item asso- 
ciated with the message. The due date property 1110 indi- 
cates a deadline for completing the action item. 



10 



15 



20 



25 



30 



35 



40 



50 



55 



65 



As mentioned above, the preferred application program 
incorporates the features of MAPI version 1.0. like other 
application programming interfaces (APIs), MAPI provides 
a variety of standardized services that simpHfy the process 
of writing code to carry out certain functions. In particular, 
the MAPI features facilitate the addition of new properties. 
This is accomplished by calling the appropriate MAPI 
function, SetProps, and providing the name and value of the 
new property. The properties are saved as part of the 
message item. Additional information is available in the 
MAPI specification. 

FIG. 12 is a flow diagram illustrating the preferred steps 
performed by a user in order to create an e-mail message that 
includes a message flag. Those skilled in the art will 
appreciate that although the method 1200 is described 
primarily in terms of steps carried out by a user, the present 
invention is a computer-implemented process that is carried 
out by the computer in response to input from the user and 
instructions provided by the preferred e-mail program mod- 
ule. 

The method 1200 begins at start step 1202 and proceeds 
to step 1205 when the user decides to create a new e-mail 
message. At step 1205, the user performs the steps associ- 
ated with the creation of a conventional e-mail message, 
including identifying the recipient(s) of the message, enter- 
ing a subject, and typing the body of the message. 

At step 1210 the user decides whether to add a specific 
action item (message flag) to the message. If not, the "no" 
branch is followed and the user proceeds to step 1215. At 
step 1215 the user sends the e-mail message, which includes 
the conventional types of data. Once the message is sent, the 
method 1200 ends at step 1220. 

If, at step 1210, the user decides to add a specific action 
item to the message, the "yes" branch is followed to step 
1225 where the user enters the message flag. This is accom- 
plished by first selecting a "flag message" command. In the 
preferred application program, this causes the computer to 
display a dialog box that provides a field for the user to enter 
the action item (i.e., the flag) and a due date, if one is desired. 
When entering the message flag, the user may type the flag, 
or select from a list of common actions items that are 
displayed in the dialog box. These items include entries such 
as call, foUow-up, forward, read, reply, etc. The list also 
includes entries such as "for your information" and "no 
response necessary" if the user wants to make it clear to the 
recipient that no response is expected. 

After the user has entered the flag at step 1225 the user 
proceeds to step 1230 and determines whether to add a due 
date to the message. If not, the "no" branch is followed to 
step 1215 where the user sends the message. If the user 
wants to add a due date, the "yes" branch is follows to step 
1235 where the user enters the deadline, which includes a 
date, and may also include a time. After the user enters the 
due date at step 1235 the user goes to step 1215 and sends 
the message, 

FIG. 13 is a state diagram illustrating the preferred 
process performed by a computer that is being used to create 
an e-mail message that includes message flag$. Although the 
method 1300 is described in terms of tasks carried out by a 
computer, those skilled in the art will appreciate that the 
present invention is a computer-implemented process that is 
carried out by the computer in response to input from the 
user and instructions provided by the preferred e-mail pro- 
gram module. 

The method 1300 begins at state 1305 with the computer 
in an idle state as it relates to instructions provided by the 
e-mail program module. When the user selects the command 
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for creating a new message, the computer proceeds to slate 
1310, where it receives the information that is typically 
associated with a conventional e-mail message. As men- 
tioned above, this includes receiving data indicative of the 
recipient(s), subject, priority, and body, and storing this data 
in association with the corresponding properties that con- 
stitute the e-mail message item. If the user then selects the 
"send" command, the computer goes to stale 1315 and 
transmits the e-mail message item. Those skilled in the art 
will understand that this may be accomphshed by calling the 
MAPISendMail and SubmitMessage functions, which carry 
out the specific steps necessary to send an e-mail message 
item, including all of the constituent properties and associ- 
ated data. After the message is sent, the computer returns to 
the idle state 1305. 

Referring again to state 1310, if the user selects the "flag 
message" command, the computer proceeds to state 1320. At 
state 1320 the computer receives the message flag data and 
due date data (if provided) from the user and stores it in 
association with the corresponding e-mail message proper- 
ties. As described earlier, the preferred e-mail program 
provides message flags by adding three properties to the 
e-mail message item. These include the status, message flag, 
and due date properties, which were discussed in conjunc- 
tion with FIG. 11. When the message flag is added at state 
1320, the action item entered by the user is stored with the 
message flag property and the deadline, if any, is stored with 
the due dale property. In the preferred e-mail system, the 
default value for the flag is "follow-up" and for the due date 
is "none." When the message flag is entered, the computer 
alters the status property to indicate that the message item 
includes a message flag and that the item is not yet com- 
pleted. The data associated with the status property typically 
is not displayed to the sender. When the user then selects the 
"send" command, the computer goes to state 1315 and 
transmits the e-mail message item in the manner described 
above. From there, the computer returns to the idle stale 
1305. 

FIGS. 14 and 15 illustrate the information that is dis- 
played to a recipient of e-mail messages that include mes- 
sage flags. FIG. 14 illustrates a "list view" of e-mail mes- 
sages received by a user of the preferred e-mail program. 
The list view is suitable for displaying a Ust of the messages 
in a user*s inbox. FIG. 15 illustrates the message view, 
which displays the complete content of a message that has 
been opened by the user of the preferred e-mail program. 

FIG. 14 illustrates a default list view 1400, which adds a 
"status" column 1405 to the information typicaUy displayed 
by prior art e-mail programs. The "status" column 1405 
indicates whether each e-mail message item includes a 
message flag and whether the action item has been marked 
by the recipient as being complete. In FIG. 14, the message 
items that include a message flag are marked with either a 
" — " or a "V." The "V" indicates that the recipient has 
marked the item as being complete. The " — " indicates that 
the item has not been completed. In another embodiment, 
the " — " and "V" icons are replaced with red and white flags. 
Messages without a message flag do not include any mark in 
the "status" column. In the preferred application program, 
the list view may be altered to display other combinations of 
information, such as the content of the message flag. 

FIG. 15 illustrates the information that is displayed in the 
message view for the preferred e-mail program. This view is 
used to display the complete content of an e-mail message 
item. The message view is displayed after a user opens an 
e-mail message from the list view (FIG. 14). In the message 
view, the preferred appHcation program displays the data 
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that is associated with prior art messages, including the 
sender, the recipient(s), the subject, and the body of the 
message. The date and time that the message was completed 
may also be displayed. In addition, messages that include 

5 message flags are displayed with an alert line 1500, which 
includes the text of the message flag 1505 and the due date 
1510 (if any). In addition, the alert line 1500 includes a 
check box 1515 that indicates whether the action item is 
complete. When the message is first opened, this box is not 
checked. The user may cHck on the box to indicate that the 
associated action item has been completed. 

FIG. 16 is a flow diagram that illustrates the steps that 
may be performed by the recipient of e-mail messages. As 
mentioned above, the present invention is a computer imple- 
mented process that is carried out by the computer in 

15 response to input fi-om the user and instructions provided by 
the e-mail program. 

As discussed earlier, in the context of message flagging, 
the recipient has several options regarding a response to 
e-mail message items. Those skiUed in the art will appreciate 

20 that the options discussed in conjunction with FIG. 16 are 
provided in addition to conventional options, such as 
deleting, replying to, and forwarding a message. Generally 
described, the recipient of e-mail messages may read 
messages, add or alter message flags, and sort and group 

25 messages based on specified properties. 

The method 1600 begins at start step 1602 and proceeds 
to step 1605 when the user opens the e-mail program module 
and reviews the items in his or her inbox, which are 
displayed in the list view (FIG, 14). At that point, the user 

30 may decide to read a message or to take some other action. 
If the user decides to read one of the messages, the user goes 
to step 1610 and opens the selected message. In the preferred 
program, a message may be opened by double clicking on 
the selected message or by selecting the message and 

35 invoking the read command. 

Once the user has read the message the user goes to step 
1615 and determines whether the message includes a mes- 
sage flag. If not, the user goes to step 1620 and decides 
whether to add a message flag, which would be appropriate 

40 if the user decides some follow-up action is required. If the 
user is satisfied that the message does not need a message 
flag, the user closes the message (step 1625). The method 
1600 terminates at step 1630. 
If, at step 1615, the user sees that the message includes a 

45 message flag, the user goes to step 1635 and determines 
whether the action item and due date (if any) associated with 
the message flag are satisfactory. If so, the user goes to step 
1625 and closes the message. If the message flag and due 
date are not satisfactory, the user goes to step 1640 and edits 

50 the information. For example, if the message flag and 
deadline indicate that a task must be completed by Friday, 
but the user wiU be out of the ofiBce on Friday, the user may 
edit the due date data to indicate that the task must be 
complete by Thursday at 5:00 p.m. Similarly, the user can 

55 edit the message to indicate that a task has been completed. 
After the message flag is edited, the user goes to step 1625 
and closes the message. 

Returning now to step 1620, if the user decides to add a 
message flag to a message that does not include one, the user 

60 goes to step 1645, At that point, the user selects the appro- 
priate command and adds the message flag and, if desired, 
due date information. This information is stored in associa- 
tion with the corresponding message item properties and 
becomes part of the message item. Once the message flag is 

65 added, the user goes to step 1625 and closes the message. 
Returning now to step 1605, the user may also decide to 
performs steps to organize or manage his or her inbox. For 
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example, the user may choose to sort messages by going to e-mail program. In one aspect, the method displays a 

step 1650. As in prior art e-mail programs, the program reminder at a predetermined period of time prior to the due 

rearranges the e-mail messages in the list view according to date. In another aspect, the method changes the display 

the values in one or more of the selected properties. For attributes of a message item in order to indicate that the due 

example, the user may sort the message by date received, by 5 date is past. Those skilled in the art will appreciate that these 

whether they are complete, etc. The method 1600 then functions are performed by comparing the due date data for 

terminates at step 1630. each message to the current time. In the preferred e-mail 

From step 1605 the user may also decide to group the program, this comparison is performed at various, predeter- 

messages according to the values associated with certain mined times. For example, the comparison is made when a 

properties. Grouping differs from sorting because grouped lo message is opened, at a predetermined time (e.g. oaidnight), 

messages are displayed in groups with dividers or separators and when a list view is redrawn, such as when a new 

between them. At step 1655, messages may be grouped message is received or the user opens a folder that contains 

according to whether they require follow-up, the type of messages. 

follow-up required, and the due date. The method 1600 then At the times described above, the computer 1800 exam- 
terminates at step 1630. 15 ines each message and determines whether the due date data 

FIG. 17 is a state diagram illustrating the preferred tasks indicates that a reminder is needed or that the action item is 

performed by the computer in response to decisions made by past due. The process begins at start step 1802 and proceeds 

the user, as described with respect to the flow diagram of to step 1805, where the computer determines whether the 

FIG. 16. Those skilled in the art will understand that the first message requires a reminder. This is accomplished by 

computer is operative to carry out the method 1700 in 20 comparing the due date data from the first message with the 

response to various inputs provided by the user. The method current time. If the due date data is within a predetermined 

1700 begins at state 1705 with the program in the idle state. time period (e.g., 2 days) of the current time, the computer 

If the user invokes an "open message" command, the goes to step 1810 and generates a reminder message, which 

computer goes to state 1710 and opens the selected message. is displayed to the user. After the reminder is displayed, or 

This allows the user to read the entire content of the message 25 if no reminder is required, the computer proceeds to step 

item. From there, the computer will do one of several things 1815. 

based on input from the user. If the user invokes the "close At step 1815 the method determines whether the due date 

message" command, the computer goes to state 1715, closes is past due. This is accomplished by comparing the due date 

the message. From there, the computer returns to the idle data to the current time. If the item is past due, the method 

state 1705. 30 goes to step 1820 and changes the display attributes of the 

If, at state 1710, the user invokes the add message flag past due message item. For example, in the list view (FIG. 

command, the computer goes to state 1720, where it receives 14), past due items may be displayed in red. After the display 

message flag and due date data from the user and stores the attributes are altered, or if the item is not past due, the 

data in association with the corresponding properties that method proceeds to step 1825. 

constitute the message item. From there, the computer 35 At step 1825, the method determines whether the inbox or 

returns to the idle state 1705. folder includes other messages that need to be checked. If so. 

If, at state 1710, the user invokes the edit message flag the method returns to step 1805 and checks the due date of 

command, the computer goes to state 1725, where it receives the next message. If not, the method terminates at step 1830. 

revised message flag and due date data from the user and From the foregoing description of the various features, 

stores the revised data in association with the corresponding 40 those skilled in the art will appreciate that message flagging 

properties that constitute the message item. From there, the faciHtates communication between the sender and recipient 

computer returns to the idle state 1705. of e-mail messages and facilitates the recipient's organiza- 

As discussed in conjunction with FIG. 16, the user may tion and management of e-mail messages. This is accom- 

decide to sort or group the messages in the inbox. Referring plished by allowing a sender to clearly indicate a foflow-up 

again to the idle state 1705, the computer proceeds to state 45 action and a due date. The recipient is able to clearly identify 

1730 if the user invokes the sort command and to state 1735 those messages that require some type of follow-up action 

if the user invokes the group command. As mentioned and the deadline for that follow-up. Furthermore, the inven- 

above, the computer sorts messages by rearranging the order tion provides reminders of upcoming due dates and an 

in which they are displayed in the list view. The order is indication that an item is past due. 

determined according to the values of one or more of the 50 In summary, the present invention benefits an e-mail 

properties selected by the user. For example, the user may sender by allowing him or her to provide a separate message 

sort the message by date received, by whether they are flag and due date regarding follow-up actions associated 

complete, etc. Those skiUed in the art will appreciate that the with a message. The present invention benefits recipients by 

sort function may be performed by calling the appropriate allowing a recipient to determine the status of a message and 

MAPI function, SortTable. Similarly, when messages are 55 to edit the message flags. Furthermore, the present invention 

grouped, they are displayed in groups with dividers or helps the recipient organize his or her inbox by providing 

separators between them. Messages may be grouped accord- sorting and grouping functions. Project management is also 

ing to whether they require foUow-up, the type of follow-up facilitated by the provision of reminders and past due 

required, and the due date. Tliose skilled in the art will notification. 

appreciate that the group function may be performed by 60 „ , , , ^ ,t ... ■ ^ ^ 

calUng the appropriate MAPI function, SortTable. After the Pf^f^"^'^ Method for Utilizmg Custom Forms 

computer groups or sorts messages, the computer returns to As described above, in the MAPI environment, a form 

the idle state 1705. provides a template that is used to display the contents of an 

FIG. 18 is a flow diagram illustrating the preferred e-mail message. For example, an e-mail message typicaUy 

process for using message flags and deadUne data for 65 includes an address field, a "From" field, a "Subject" field, 

generating reminders for the user. These steps are carried out and a "Body" field. The user composes an e-mail message by 

by the computer in response to instructions provided by the entering data into the appropriate fields and then sends the 
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message to the recipient. For example, a user may enter previously "published" or that the user or the recipient 

"Lunch'* in the "Subject" field and enter "Where would you instaU the form in a memory device before sending or 

like to eat?" in the "Body" field. The form allows the sender receiving a message item that uses the form, 

and recipient of an e-mail message to view the fields and When a recipient receives an e-mail message, it is deter- 

data entered into those fields. A form contains layout infor- 5 mined whether the message item has a "form" property. If 

maiion that specifies the layout, or arrangement, of the the message item includes a "form" property, then the value 

fields. in the "form" property is read to extract layout information. 

As previously discussed, there are times when a user feels The layout information is used to display the message item, 
that available forms simply do not meet his or her require- including the fields, in the proper placement and arrange- 
ments and that it would be useful to create a custom form lo ment. 

that allows the viewing of additional fields, A custom form Preferably, the creation of a custom form is accomplished 

is one in which the user has added fields, deleted fields, using the preferred application program, which is the 

and/or rearranged fields to suit a particular need. As those "MICROSOFT OUTLOOK" personal information manager, 

skilled in the art will understand, several prior application Thus, the following description of the creation of a custom 

programs allow users to create custom forms. These pro- ^5 ^ gj^^n with reference to the commands and steps 

grams include the forms design utility in the "MICROSOFT executed when creating a form using the "MICROSOFT 

EXCHANGE" program published by Microsoft OUTLOOK" personal information manager. 

Corporation, the "LOTUS NOTES" groupware message pjc. 20 is a flowchart, from the sender's perspective, of 

application program published Lotus Development t^e steps performed in creating and sending an e-mail 

Corporation, and the "JETFORM FOR E-MAIL" program 20 ^^^^^^^ ^^^^ ^ ^,^3^^^^ Although the method is 

published by JetForm Corporation. described below in the context of a user executing certain 

In the prior art, after the creation of a custom form, the steps and a computer performing certain steps, those skilled 

custom form is typically "published," or stored on a central in the art will understand that the present invention is a 

file server. Each user was then required to install the form on computer-implemented process carried out by a computer in 

their computer. Before using the custom form, all users, both response to both user input and instructions from an e-mail 

users sending a message item containing the custom form program module. 

and users receiving a message item containing the custom xhe method 2000 begins at the start step 2002 and 

form, had to install the custom form on their operating proceeds to step 2005 when the user opens a new e-mail 

system. Thus, the prior art has not provided a convenient message. As those skilled in the art wiU understand, the new 

method for users to quickly create a custom form and to send message will be displayed using a previously installed form, 

and receive a custom form. or standard form. A standard form supplied by MAPI 

As mentioned earlier, an e-mail message, or e-mail item, includes fields such as an address field, a "From" field, a 

includes a plurality of properties. Each property includes a "Subject" field, and a "Body" field that are commonly used 

property tag and value, which are stored together in system 35 in a message. 

memory 15 (FIG. 1) as a single data structure. In most cases. At step 2010, the user decides whether to use one of the 

the properties correspond to a field that is displayed. FIG. 19 previously installed forms or to create a custom form for the 

illustrates an e-mail message item 1900 that includes a e-mail message. If the user decides to use a previously 

plurality of properties. These include the standard properties installed form, the user proceeds to step 2015 and composes 

1905, such as a "sender" property 1910, a "recipient(s)" the e-mail message. In other words, at step 2015, the user 

property 1915, a "subject" property 1920 and a "body" performs the steps associated with the creation of a conven- 

property 1925. tional e-mail message, including identifying the recipient(s) 

The preferred e-mail module uses an additional property of the message, entering a subject, and typing in the text of 

to provide a method and system for creating a message item the message. After the user has composed the message, then 

that uses a custom form. Generally described, a description 45 the user sends the message. Once the message is sent, the 

of the custom form is stored in a property of the e-mail method 2000 ends at step 2020. 

message, and is transmitted to the recipient as part of the If, at step 2010, the user decides to design a custom form 

message. This eliminates the need for the form to be for the message, the user proceeds to step 2025 and cus- 

installed on the recipient's computer prior to receiving the tomizes the form, or designs the custom form. This is 

new message. 50 accomplished by first selecting a "design forms" option. In 

In the preferred e-mail system, an existing form, or the preferred application program, selecting the "design 

standard form, can be modified by the user by rearranging forms" option shifts the application program into design 

fields and adding new fields, if necessary, to create the layout mode. When the preferred application is in design mode, a 

of fields desired by the user. The modified form is referred dialog box known as a field chooser is displayed. The field 

to as a custom form. As illustrated in FIG. 19, in the 55 chooser 2100, which is shown in FIG. 21, is a dialog box that 

preferred embodiment, a value corresponding to the layout provides a list of fields that the user may add to the displayed 

information of the custom form and a "form" property tag form. For example, a field chooser may contain a list of 

are stored together as a "form" property 1930 in the e-mail fields such as "Cc" 2105, "Conversation Topic" 2110, "Do 

item 1900. The "form" property is sent to the recipient with not Auto Archive" 2115, "From" 2120, "Icon" 2125, 

other properties of the mail item. The value stored in the 60 "Importance" 2130, "Message" 2135, "Received" 2140, and 

form property 1930 contains layout information for the "Sent" 2145. 

standard properties 1905 and the custom properties 1935. When customizing a form, the user selects a field from the 

The standard properties correspond to the fields that were field chooser 2100 and adds this field to the form. The field 

included in the standard form. The custom properties cor- chooser also provides an option that allows a user to create 

respond to the fields that were added by the user when 65 a new field, if the fields listed in the field chooser do not 

customizing the standard form. In contrast to the prior art, meet the needs of the user. The user preferably creates a new 

the preferred embodiment does not require that the form be field by selecting the "new field" option 2150 in the field 
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chooser. Then, the user enters a name, type, and format for form. The user can rearrange the fields until the fields are in 
the new field. After the new field is created, the preferred the location and position desired by the user. When the user 
application program adds the new field to the field chooser. has finished rearranging the fields, the user selects a corn- 
Then, the user can select the new field from the field chooser mand to return to run mode and the computer proceeds to 
and add it to the standard form. It will be imderstood by 5 state 2240. At state 2240, the computer displays the custom 
those skilled in the art that any previously installed form can form, that is, the standard form with added fields, with the 
be customized using the method outlined above. fields in the position determined by the user. In run mode. 

Referring again to FIG. 20, after the user has designed the the user may enter data corresponding to the fields of the 

form at step 2025, the user proceeds to step 2030 and returns custom form, but may not rearrange fields or add and delete 
the application program to run mode. ITiis is accomplished lo fields as can be accomplished in design mode, 

by selecting a "nm mode" command. If the user composes the message, i.e. enters data corre- 

After reluming the application program to run mode, the sponding to one or more fields of the custom form, the 

user composes and sends the message at step 2015 as computer proceeds to state 2215 and the data entered into the 

described above. The method then ends at step 2020. fields is stored in the properties corresponding to the fields. 

FIG. 22 is a state diagram illustrating the functions "^^^^ selects the send command, the computer 

performed by a computer that is being used to create an proceeds to state 2220 and transmits the e-mail item. After 

e-mail message that uses a custom form. The method 2200 message is sent, the computer returns to the idle state 

begins at state 2205 with the computer in an idle state as it 2205. 

relates to instructions provided by the e-mail program mod- FIG. 23 is a representative example of the user interface 

ule. When the user selects the command for creating a new that is displayed by the preferred e-mail program module to 

message, the computer proceeds to step 2210, where it the sender of an e-mail message that uses a custom form, 

displays the standard form for an e-mail message. The The e-mail message 2300 includes three fields that have 

standard form includes fields to enter data or compose the been added by the sender of the message. These fields are a 

message. If the user enters data for one or more of these "Length" field 2305, a "Width" field 2310, and a "Height" 

fields, the computer goes to state 2215 and stores the field 2315, It will be understood that these fields have been 

constituent data in properties of the e-mail item correspond- added to a conventional e-mail message in accordance with 

ing to these fields. When the user selects the "send" the preferred e-mail system. The present invention is not 

command, then the computer goes to state 2220 and trans- limited to the addition of these fields to an e-mail message, 

mils the e-mail message item. After the message is but can be extended to the addition of more (or fewer) 

transmitted, the computer returns to the idle state 2205. custom fields. In addition, the present invention may be used 

Referring again to state 2210, if the user chooses the to simply rearrange the fields of a conventional e-mail 

"design forms" command, the computer proceeds to state message without adding any fields. Those skilled in the art 

2225. At state 2225, the computer shifts the preferred e-mail will appreciate that the data entered in these fields is stored 
program module firom run mode to design mode. In design 35 ^ value in the corresponding properties of the e-mail 

mode, the user may customize, or edit, the displayed form by message item (FIG. 19). 

adding and/or rearranging fields. When the user selects the Thus, firom the foregoing description, it will be obvious to 

"design forms" option, the computer also displays a field those skilled in the art that the present invention provides a 

chooser dialog box at state 2225. method for creating and sending an e-mail message that 
If the user selects a field from the field chooser dialog box 40 includes a custom form. The data corresponding to the 

to be added to the standard form, then the user drags the field custom form is stored in a property of the e-mail message 

off of the field chooser dialog box and onto the custom form. item along with the other properties of the message. The 

The user "drags" the field off of the field chooser dialog box custom form does not need to be installed on a memory 

using a mouse 29 (FIG. 1) or similar input device. The storage device or stored in a form registry provider 500 
computer adds the field to the displayed form and continues 45 (FIG. 5) before being used. 

to display the field chooser dialog box at state 2225. Having described the method for creating and sending an 

If the user selects the "new field" command, the computer e-mail message that includes a custom form, a description of 

proceeds to state 2230. At state 2230, the computer displays the method for receiving a message with a custom form will 

a new field dialog interface. The new field dialog interface now be presented. When the preferred e-mail program 
includes blanks to enter the name, type, and format of the 50 module is used to open a message that has been received, the 

new field. A toolbox is also displayed. The toolbox has module determines whether the message item has a "form" 

buttons corresponding to different tools that can also be used property. If the message item has a "form" property, the 

to create new fields on the form. For instance, the user can layout information, stored as a value in the "form" property, 

select the radio button tool from the toolbox and create a is read and used to view the contents of the e-mail message, 
new radio button on the form. After the user enters the name, 55 If the message item does not have a "form" property, then 

type, and format of the new field or adds a field using the the layout information is read from the MAPI form registry 

toolbox then the user selects the "OK" command. After the provider 500 (FIG. 5) and the message item is displayed, 

user selects the "OK" command, the computer returns to The only action performed by a recipient is to open the 

state 2225. As described above, at state 2225, the computer e-mail message. The e-mail program module will determine 
displays a field chooser dialog box. After the user has added eo where to find the form and will extract the layout informa- 

a new field, the computer will display the field chooser tion from the appropriate source. 

dialog box including the new field that was added. FIG. 24 is a flow diagram of the steps performed by a 

Referring again to stale 2225, if the user is finished adding recipient's computer in displaying a received message item, 

fields, then the user closes the field chooser dialog box. The method 2400 begins at start step 2402 and proceeds to 
When the field chooser is closed, the computer proceeds to 65 step 2405 when the computer receives a command from the 

state 2235. At state 2235, the computer displays the standard user to open a message item in the user's inbox. After the 

form and the new fields that have been added to the standard computer receives a command to open a message item, the 
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computer proceeds to step 2410 to determine whether the 
message item includes a ''form" property. If not, the com- 
puter proceeds to step 2415 and selects the appropriate form 
layout information, of form data, from the form registry 
provider. After extracting the layout information from the 5 
form registry provider, the computer combines the data from 
the message item with the layout information from the form 
registry provider and displays the message at step 2420. The 
display of the message includes display of the fields and the 
field data in the fields. As those skilled in the art will 
understand, the field data is stored as values in properties in 
the message item. When displaying a message item, the 
value in a property is extracted and displayed in the corre- 
sponding field. At step 2425, the method ends. 

Returning to step 2410, if the computer finds a "form" .^5 
property in the message item, then the computer proceeds to 
step 2430. At step 2430, the computer extracts the value, or 
layout information, stored in the "form" property of the 
message item. As will be apparent to those skilled in the art, 
die layout information is the binary data, or value, that is 
stored in the "form" property. Using this layout information, 
the computer combines the data from the message item with 
the display information in the message's "form" property 
and displays the message item at step 2420. At step 2425, the 
method ends. 25 

The information that is displayed to the recipient of an 
e-mail message that uses a custom form, i.e., the "read" 
page, is preferably the same as the information that is 
displayed to the designer of the message, i.e., the "compose" 
page. For example, the e-mail message 2300 in FIG. 23 30 
includes three fields that were added by the sender of the 
message. The display illustrated in FIG. 23 is the "compose" 
page. The e-mail message displayed to the recipient, the 
"read" page, of the message in FIG. 23 preferably has the 
same information and arrangement as the "compose" page. 35 
Thus, a recipient of an e-mail message that tises a custom 
form does not need to install the custom form before opening 
the message. In addition, as further described below, the 
present invention provides a method for responding to an 
e-mail message that uses a custom form. 43 

Those skilled in the art will appreciate that when a 
recipient of an e-mail message with a custom form replies to 
the message, the "form" property and its associated fields are 
used in the reply message. When composing the reply, the 
user may alter the data in the fields that constitute the custom 45 
form, in which case the new data is stored in the properties 
associated with those fields. Furthermore, the user may 
further customize the form by selecting the "design form" 
option. In this case, data corresponding to the layout of the 
newly customized form is stored in the e-mail message's 50 
form property. When the reply is sent, the transmitted 
message item includes the form property and properties 
corresponding to the constituent data. Thus, the process of 
replying to a message is substantially similar to the process 
described in conjunction with FIGS. 20 and 22. 55 

As mentioned above, the "read" page and "compose" 
page of a custom form are preferably displayed the same. 
However, an embodiment of the present invention allows the 
designer of a custom form to design the "read" and "com- 
pose" pages to be displayed differently from one another. 60 
For example, the "compose" page in FIG. 23 has exphcit 
fields, a "Length" field 2305, a "Width" field 2310, and a 
"Height" field 2315. The "read" page of a message using a 
form with these fields may be designed to be displayed as in 
FIG. 25. The "read" page of the message 2500 in FIG. 25 65 
displays only a "dimensions" field 2505, which combines 
the data from the "Length" field, the "Width" field, and the 
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"Height" field. Thus, the designer of a custom form can 
design the "read" page to display differently than the "com- 
pose" page. In addition, the designer of a custom fonm may 
also design a form such that certain fields may not be 
changed in the "read" page. 

From the foregoing description, those skilled in the art 
will appreciate that the present invention facilitates commu- 
nication between e-mail users by allowing users to create, 
use and share custom forms spontaneously without requiring 
publication or installation on other users* computers. This 
allows small work groups to develop their own tools without 
requiring company-wide publication of forms. 

The Preferred Method for Tallying E-mail 
Responses 

E-mail systems provide an effective means of communi- 
cating with a large number of individuals in an organization, 
such as by sending a single e-mail message to a number of 
different individuals. Many times, an e-mail message is sent 
to a number of individuals in order to solicit a response to 
a particular query. For example, an oflBce administrator may 
send an e-mail message to all of the employees in an office 
asking, "Will you attend the office breakfast?" As another 
example, an e-mail user may send an e-mail message to his 
or her co-workers fisting several restaurants and asking, "At 
which restaurant would you like the Christmas party held?" 

Although prior art e-mail systems make it easy to ask a 
question of a group of people, the prior art has not provided 
any convenient or effective way for the sender to organize 
the responses once they are received. The present invention 
allows a sender of an e-mail message to create an "autore- 
sponse message" with "voting buttons," which correspond 
to possible responses to the question addressed in the e-mail 
message. When each recipient opens the autoresponse 
message, he sees the question in the body or subject field of 
the e-mail message and a command bar with voting buttons 
at the top of the message. To respond, the recipient selects 
one of the voting buttons in the command bar, edits the reply 
(if desired), and sends the reply. When the sender's e-mail 
program receives an autoresponse reply from a recipient, the 
reply is recognized as an autoresponse reply and the recipi- 
ent's vote is tallied in the sender's copy of the original 
message, which is referred to as the "sent mail copy." When 
the sender opens his or her sent mail copy of the original 
autoresponse message, he or she is able to view a list that 
includes the name of each recipient, their response, the time 
of their response, and a tally of the voting results. 

As mentioned earher, an e-mail message, or e-mail item, 
includes a plurality of properties. Each property includes a 
property tag and value which are stored together in system 
memory 15 (FIG. 1) as a single data structure. In most cases, 
the properties correspond to a field that is displayed. FIG. 26 
illustrates an e-mail message item 2600 that includes a 
plurality of properties. These include the standard 
properties, such as a "sender" property 2605, a "recipient(s)" 
property 2610, a "subject" property 2615, and a "body" 
property 2620. When an e-mail message is transmitted to the 
recipient, the property tags and values are transmitted to the 
recipient via a network. 

Message items also typically contain a property or prop- 
erties used by the e-mail program module to track whether 
an e-mail item has been sent, received, read, etc. These 
properties are usually not displayed to the user. An example 
of such a property is the MAPI property PR__REPORT_ 
TAG. The value stored in a PR_REPORT__TAG property is 
known as a moniker. The moniker contains data identifying 
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the message store in which the sent nnail copy of a message 
was stored. The moniker also contains data identifying the 
folder in which the sent mail copy of the message was stored 
when the original message was sent. The moniker further 
contains a search key number, which is a unique number that 5 
identifies the sent mail copy of the message. Thus, the 
moniker allows an e-mail program module to locate the sent 
mail copy of an e-mail message, so that it can be updated 
when the original message has been sent, received, read, etc. 

As illustrated in FIG. 26, the preferred e-mail module uses 
additional properties to provide the autoresponse feature. 
The additional properties include a "my vote" property 
2625, an "autoresponse verbs" property 2630, a "PR_„ 
REPORT_TAG" property 2635, and at least one "voter" 
property 2640, which correspond to the names of the recipi- 15 
ents 2645 of the e-mail message. 

The "autoresponse verbs" property 2630 has a value that 
corresponds to the possible responses, or choices, that can be 
sent in reply to an autoresponse message query. For 
example, as shown in FIG. 26, if an autoresponse message 
includes the query "At which restaurant would you like the 
Christmas party held?" and the possible choices of restau- 
rants are Chez Jean, Mama Rosa's, and Big Bob's, then the 
value stored in the "autoresponse verbs" property is "Chez 
Jean, Mama Rosa's, Big Bob's." The "my vote" property 
2625 is a property with a value corresponding to the vote of 
the recipient. The value associated with the "my vote" 
property is empty in the original autoresponse message item. 
When the recipient enters their vote, an autoresponse verb is 
executed as will be further described below. One of the 
actions associated with an autoresponse verb is to store the 
name of the autoresponse verb as the value of the "my vote" 
property in the autoresponse reply message. 

"Recipient name'* properties 2640 corresponding to the 
name of each recipient 2645 are also used to implement the 
autoresponse feature. The value of each "voter** property is 
empty in an autoresponse message item and in an autore- 
sponse reply. Each autoresponse reply message is used to 
update the sent mail copy of the autoresponse message. The 
value corresponding to the "my vote" property in the auto- 
response reply message is stored in the "voter" property of 
the sent mail copy of the autoresponse message. For 
example, when Jim receives an autoresponse message, he 
selects one of the voting buttons to enter his vote. The data 
corresponding to Jim's vote is stored as the value in the "my 
vote" property of Jim's autoresponse reply message. When 
Jim's autoresponse reply message is received by the e-mail 
program module of the sender of the original autoresponse 
message, the sent mail copy of the autoresponse message 
will be updated to reflect Jim's vote. Specifically, the "voter" 
property, "Jim," in the sent mail copy of the autoresponse 
message is updated to reflect the same value as the "my 
vote" property in the autoresponse reply from Jim. 

Having described the additional properties employed by 55 
the preferred e-mail module to implement the autoresponse 
feature, we turn now to the e-mail form used to execute the 
autoresponse feature. As described above in the section 
entitled "The Messaging Application Programming Inter- 
face (MAPI)," a form is a viewer for a message. Client go 
application developers can create custom forms. These cus- 
tom forms implement a set of standard menu commands 
(such as open, create, delete and reply) and a set of com- 
mands specific to that particular form. 

The commands implemented by a form are also known as 65 
verbs. A set of actions, or steps, is performed when a verb 
is selected by a user of an e-mail program module. As an 
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example, when a user of an e-mail program module selects 
the reply verb or command, several actions typically occur: 

(1) the value of the recipient property in the original message 
is stored as the value of the sender property in the reply 
message; (2) the value of the sender property in the original 
message is stored as the value of the recipient property in the 
reply message; (3) the characters "Re:" are added to the 
value of the subject property in the original message, and 
this combined data is stored is stored in the subject property 
in the reply message, and (4) the value of the body property 
in the original message is stored as the value of the body 
property in the reply message. 

The preferred e-mail program module uses a custom form 
and custom verbs to implement the autoresponse feature, 
Th& custom form includes custom verbs known as autore- 
sponse verbs. As mentioned above, each autoresponse verb 
corresponds to a voting button. When a voting button is 
selected by a recipient of an autoresponse message, the 
autoresponse verb associated with that voting button is 
executed. Each autoresponse verb executes the same three 
actions: (1) an autoresponse reply message item is created; 

(2) the name of the autoresponse verb that was executed is 
stored as the value of the "my vote" property of the reply; 
and (3) the name of the autoresponse verb is stored, along 
with the value of the "subject" property of the original 
message, as the value of the "subject" property of the reply. 

Having presented a basic overview of properties, forms, 
and fields, a detailed description of the steps performed by 
a user to create an autoresponse e-mail message will be 
presented below. 

FIG. 27 is a flow diagram that illustrates the steps 
performed by a user to create an autoresponse e-mail mes- 
sage. Although the method of creating, sending, and reply- 
ing to an autoresponse e-mail message is described below in 
the context of a user executing certain steps and a computer 
performing certain steps, those skilled in the art will under- 
stand that the present invention is a computer- implemented 
process carried out by a computer in response to both user 
input and instructions from an e-mail program module. 

The method 2700 begins at start step 2702 and proceeds 
to step 2705 when the user decides to create a new e-mail 
message. At step 2705, the user performs the steps associ- 
ated with the creation of a conventional e-mail message, 
including identifying the recipients of the message, entering 
a subject, and typing in the text of the message. 

At step 2710, the user decides whether to activate the 
autoresponse feature. If the user decides not to activate 
autoresponse, then the user proceeds to step 2715 and sends 
the e-mail message. After the message is sent, the method 
2700 ends at step 2720. 

If, at step 2710, the user decides to activate autoresponse, 
the user proceeds to step 2725, activates the autoresponse 
feature, and enters a set of possible responses to the query 
presented in the message. Referring now to FIG. 28, acti- 
vating the autoresponse feature is preferably accomplished 
by selecting an options page 2805 of the e-mail program 
module and clicking a "use voting buttons" checkbox 2810, 
In the preferred e-mail program module, this results in the 
display of an entry blank 2815 and a drop-down menu 2820. 
The user then may enter each possible predefined response, 
separated by a semicolon, into the displayed entry blank. 
Each possible response entered by the user is known as a 
token. For example, if the query posed in the e-mail message 
is "At which restaurant would you like the Christmas party 
held?," the user might enter the tokens 2825 by typing in the 
names of several diflferent restaurants, such as Chez Jean- 
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;Mania Rosa's;Big Bob's as shown in FIG. 28. As men- 
tioned above, the preferred application program also dis- 
plays a drop-down menu 2820 when the "use voting 
buttons" checkbox is selected. The drop-down menu 
includes pre-defined token sets 2830. The pre-defined token 5 
sets are combinations of tokens that are frequently used, 
such as Approve; Reject, Yes; No, and Yes;No;Maybe. Thus, 
when a user needs to use one of the predefined token sets 
2830, the user selects the pre-defined token set in the 
drop-down menu rather than entering the tokens into the lo 
entry blank. 

Returning to FIG. 27, after the user enters the tokens at 
step 2725, the user proceeds to step 2715 and sends the 
e-mail message. Therefore, to create an autoresponse 
message, the user creates an e-mail message, activates the 
autoresponse feature, enters tokens, and sends the autore- 
sponse message. The functions performed by the computer 
of the sender of an autoresponse message are described 
below in reference to FIG. 29. 

FIG. 29 is a state diagram illustrating the functions 
performed by a computer that is being used to create an 
e-mail message that includes the autoresponse feature. The 
method 2900 begins at state 2905 with the computer in an 
idle state as it relates to instructions provided by the e-mail 
program module. When the user selects the command for 
creating a new message, the computer proceeds to state 
2910, where it receives the information that is typically 
associated with a conventional e-mail message. This 
includes receiving data indicative of the recipients, subject, 
priority, and body, and storing this data as values in the 
corresponding properties that constitute the message item. If 
the user then selects the "send" command, the computer 
proceeds to state 2915 and transmits the e-mail message 
item. After the message is sent, the computer returns to the 
idle state 2905. 

Referring again to state 2910, if the user selects the 
options page and clicks a "use voting buttons" checkbox, the 
computer proceeds to state 2920. At state 2920, the com- 
puter adds the autoresponse properties to the message item. 
As mentioned above, the creation of new message properties 
is facilitated by the MAPI function SetProps. To add the 
"autoresponse verbs" property, the computer receives a set 
of tokens entered by the user. The computer creates a custom 
verb from each token and stores the data indicative of the 
name of each verb as the value of the "autoresponse verbs" 
property. 

At state 2920, the computer also adds a "my vote" 
property and "voter*' properties corresponding to the names 
of each of the recipients to the message item. The "my vote" 
property and the "voter" properties do not have any data 
stored as their value when they are added to the autoresponse 
message. At state 2920, the computer also stores a moniker 
in the PR_REPORT_TAG property. 

When the user selects the "send" command, the computer 55 
proceeds to state 2915 and transmits the autoresponse mes- 
sage item. The computer also stores a sent mail copy of the 
autoresponse message. The sent mail copy is preferably 
stored in the sender's sent mail folder, but the sent mail copy 
may be stored in another memory storage location specified go 
by the sender. The sent mail copy of the autoresponse 
message will be updated when recipients reply to the auto- 
response message. This updating will be described below in 
reference to FIG. 34. 

Turning now to the process of receiving an autoresponse 65 
message, FIG. 30 is a flow diagram that illustrates the steps 
that may be performed by a recipient of an autoresponse 
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message. The method 3000 begins at start step 3002 and 
proceeds lo step 3005 when the user opens an e-mail 
message item with the autoresponse feature. After opening 
the message, the user may read the text of the message, 
including the query presented by the sender of the autore- 
sponse message. For example, in the preferred application 
program, the user, after opening an autoresponse message, 
views a message 3100 such as is shown in FIG. 31. The 
autoresponse message is similar to a conventional e-mail 
message and includes a "from" field 3105, an address field 
3110, a "Cc" field 3115, a "subject" field 3120, and a "body" 
field 3125. The autoresponse message also includes the 
voting buttons 3130. 

Referring again to FIG. 30, after the user has opened and 
viewed the message at step 3005, the user selects one of the 
voting buttons at step 3010. When the user selects one of the 
voting buttons, an alert box message will appear that will 
warn the user that their reply will now be sent. The alert box 
message asks the user if he would like to edit the reply 
before sending the reply message. At step 3015, the user 
decides whether to edit his reply before sending the mes- 
sage. If the user decides not to edit his reply, then the user 
clicks the "send" button at step 3020. The method ends at 
step 3025. 

Returning to step 3015, if the user decides to edit his 
response, then the user enters data into the body field of the 
autoresponse reply at step 3030. When the user decides to 
send the autoresponse reply message, the user proceeds to 
step 3020 and sends the message. The method ends at step 
3025. 

Therefore, a recipient of an autoresponse message needs 
only to execute a few simple steps to reply to an autore- 
sponse message. The recipient opens the autoresponse 
message, reads the query presented in the message, selects 
a voting button, edits the reply (if necessary), and sends the 
autoresponse reply to the sender. The functions performed 
by a computer of a recipient who is replying to an autore- 
sponse message are described below. 

FIG. 32 is a state diagram illustrating the functions 
performed by a computer that is being used to open and 
reply to an autoresponse e-mail message. The method 3200 
begins at step 3205 with the computer in an idle state as it 
relates to instructions provided by the e-mail program mod- 
ule. If the user invokes an "open message" command, the 
computer goes to state 3210 and opens the selected autore- 
sponse message. The computer searches the message item to 
locate the "autoresponse verbs" property. As described 
above, the responses, or tokens, entered by the sender of the 
message are used to create "autoresponse verbs." The data 
indicative of the names of these autoresponse verbs are 
stored is stored as a value in a property called autoresponse 
verbs. The computer reads the value of the "autoresponse 
verbs" property and displays voting buttons corresponding 
to each autoresponse verb. 

If the user selects a voting button, then the computer 
proceeds to state 3215. At state 3215, the computer executes 
the "autoresponse verb" corresponding to the voting button. 
As described above, when an autoresponse verb is executed, 
the computer stores the data corresponding to the name of 
the autoresponse verb chosen by the recipient as the value in 
the "subject" property of the reply message. The computer 
also stores the data corresponding to the name of the 
autoresponse verb selected by the recipient as the value in 
the "my vote" property of the reply message. Also, the 
PR_REPORT_TAG property associated with the original 
message is copied by the computer into the reply message. 
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Returning to state 3215, if the user decides to send the 
autoresponse reply niessage without editing, then the com- 
puter proceeds to slate 3220 and transmits the autoresponse 
reply. The computer then returns to the idle slate 3205. 

If the user does decide to edit the reply message, then the 
computer proceeds to slate 3225. At state 3225, the com- 
puter receives data indicative of changes to the fields of the 
message and stores this data as the value of the correspond- 
ing property in the message item. When the user sends the 
message, the computer proceeds to state 3220 and transmits 
the message. 

When an autoresponse reply is sent back to the original 
sender of the autoresponse message, the reply is processed, 
i.e., the voting results are updated, when the reply message 
is opened for the first time. The reply may be opened in a 
conventional manner by the user selecting an open com- 
mand for the autoresponse reply. The autoresponse reply 
may also be processed in the background, i.e., without any 
input from the user, by an automatic processor known as a 
sniffer. The sniffer ensures that autoresponse repfies are 
processed in a timely manner even if the user never opens 
the replies. FIG. 33 is a flow diagram illustrating the 
functions performed by the sniffer when an autoresponse 
reply is received. The method 3300 begins at step 3305. The 
sniffer determines at step 3305 whether the computer is idle. 
If the computer is idle, the sniffer proceeds to step 3310 to 
determine whether there is a message to sniff. This is 
preferably done by searching a "sniff state" properly that is 
associated with unread messages. The "sniff state" property 
can have three values: "none, " "on sniff," or "on open only." 
If the "sniff state" property is "on stiff," then the message is 
processed by the sniffer. If the "sniff state" property is 
"none" or "on open only," the sniffer returns to step 3305 to 
determine whether the computer is still idle. 

Returning to step 3310, if the sniffer finds a message with 
a value of "on sniff" in its "sniff state" property, the sniffer 
proceeds to step 3315 and processes the autoresponse 
response message item. After processing the autoresponse 
response message item at step 3315, the sniffer closes the 
autoresponse response message item at step 3320. The 
sniffer then proceeds to step 3305 to determine whether the 
computer is still idle. 

Thus, those skilled in the art will recognize that the sniffer 
will process an autoresponse reply message item even if the 
original sender never opens the reply. In addition, an auto- 
response reply message item will be processed even if the 
user deletes the message item before the sniffer is able to 
process the message item. When a user deletes the autore- 
sponse reply message item, the original message will be 
updated to reflect the content of the reply before the message 
item is deleted. Because of these features, the user does not 
have to open each and every response to tally results. 
Instead, the user may simply open the "sent mail" copy of 
the autoresponse message to view the voting results. 

FIG. 34 is a state diagram illustrating the functions 
performed by a computer that is being U5ed to update the 
sent mail copy of an autoresponse message. The method 
3400 begins at step 3405 with the computer in an idle state 
as it relates to instructions provided by the e-mail program 
module. When the user selects the command to open an 
autoresponse response item or the sniffer opens an autore- 
sponse response item, the computer proceeds to state 3410. 
The computer reads the value of the PR_REPORT_TAG 
property of the autoresponse response in stale 3410. The 
value of the PR_REPORT_TAG is known as a moniker. 
The moniker contains information used to locate the original 
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autoresponse message on the sender's computer. The origi- 
nal autoresponse message must be found to update the 
original message with the votes of the recipients. 
Specifically, the moniker contains data corresponding to the 

5 message store that the original message was stored in, the 
folder that the original message was stored in, and a search 
key. Returning to step 3410, the computer reads the moniker 
and searches the computer's memory storage devices for a 
message store that corresponds to the message store identi- 

10 fied in the moniker. 

Once the computer finds the proper message store, the 
computer proceeds to step 3415. At step 3415, the computer 
searches the message store for a folder that corresponds to 
the folder identified in the moniker. After the proper folder 

15 is found, the computer proceeds to step 3420. At step 3420, 
the computer opens the folder and searches for a message 
with a search key corresponding to the search key identified 
in the moniker. The message with the corresponding search 
key is the original autoresponse message. After the original 

20 autoresponse message is found, the computer proceeds to 
step 3425, It will be appreciated that, at any point in the 
process of finding the original message, the process could 
terminate if the proper message store, proper folder, or 
proper message is not found. 

At step 3425, the computer opens the original autore- 
sponse message and searches for a "voter" property corre- 
sponding to the value of the "sender" property of the 
autoresponse reply. For example, if Bob receives an original 
autoresponse message and responds by selecting a voting 
button, then the autoresponse reply from Bob wiU contain 
data indicative of "Bob" in the "sender" properly. When the 
autoresponse reply is opened, the computer finds the original 
autoresponse message as described above in reference to 
states 3410-3420. The computer then opens the original 
autoresponse message and searches for the "voter" property 
corresponding to "Bob." 

After the "voter** property is found at state 3425, the 
computer proceeds to step 3430. The computer updates the 
value of the "voter" property with the value of the "my vote" 
property of the autoresponse reply. After the sniffer or the 
user closes the autoresponse reply, then the computer returns 
to idle state 3405. 
When a sender of an autoresponse message wants to view 

45 the replies to his or her message, the sender may view each 
individual reply to the autoresponse message. For example, 
FIG. 35 illustrates the inbox 3500 of a e-mail program 
module in a list view. Message 3505 and message 3510 are 
autoresponse reply messages. The name of the autoresponse 

50 verb 3515 chosen by the recipient 3520 of the autoresponse 
message is listed under the subject heading of the inbox 
before the original subject of the autoresponse message. It 
will be understood that including the recipient's "vote" in 
the subject of the message provides a distinct advantage over 

55 the prior art. The user does not need to open the response in 
order to read the vote of the recipient because it is already 
listed in the subject heading. Furthermore, it will be apparent 
that the sender of the autoresponse message can open the 
individual reply messages and read the vote of the recipient 

50 and any comments the recipients may have edited into their 
reply. However, because of the sniffer, the sender of an 
autoresponse message does not have to open each individual 
reply message to tally the results since the sniffer will 
process the replies in the background. 

65 In addition to viewing the inbox, the sender of an auto- 
response message can open his or her sent mail copy of the 
autoresponse message. When the sender opens the sent mail 
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copy of the auto response message, he views a list of the 
recipients 3605, their responses 3610, the time 3615 each 
response was received, and a current tally 3620 of the vote 
results such as is illustrated in FIG. 36. 

As known to those skilled in the art, the current tally for 
each vote is found by computing the number of recipients 
that have responded with that vote. 

In another embodiment, when the sender opens a reply to 
the autoresponse message, the computer displays a list of the 
results such as is shown in FIG. 36. Thus, in this 
embodiment, the sender can view the results by opening any 
reply message rather than locating and opening the sent mail 
copy of the autoresponse message. 

From the foregoing description, those skilled in the art 
will appreciate that autoresponse messages facilitate com- 
munication between the sender of an e-mail message con- 
taining a query and the recipients of the e-mail query. This 
is accomplished by allowing the sender of the e-mail mes- 
sage to add voting buttons that correspond to the possible 
responses to the e-mail query. To reply, each recipient 
simply selects a voting button and sends their reply. When 
the replies are received at the sender's e-mail program 
module, the votes are automatically tallied by a background 
process, known as a sniffer, or when the sender opens a 
reply. However, because of the automatic processing of the 
sniffer, the sender does not have to open every e-mail reply 
to see the voting results. Instead, the sender simply opens a 
sent mail copy of the e-mail query to view the voting results. 
When the sent mail copy is opened, the sender may view a 
list of the recipients, their response, the time their response 
was received, and a current tally of the voting results. 

SUMMARY OF THE DETAILED DESCRIPTION 

From the foregoing description, it will be appreciated that 
the present invention provides an improved system and 
method for processing and organizing e-mail message items. 
The preferred system and method are embodied in an e-mail 
module that forms a part of a personal information manager 
program. In summary, recipient names are resolved in the 
background while the user composes the remainder of the 
message. Unambiguous names are resolved without further 
intervention by the user. The user resolves ambiguous names 
by selecting from a list of possible matches displayed in a 
context menu. The e-mail module remembers how ambigu- 
ous names are resolved and automatically creates nicknames 
for future use. In addition to a subject and body, each e-mail 
message may contain a message flag, which specifically 
identifies follow-up actions that need to be performed and 
deadlines for those actions. The message flag and due date 
are stored in message properties and may be edited by either 
the sender or the recipient. The message flags allow a 
recipient to quickly determine which messages have action 
items associated with them, when they are due, and whether 
they have been completed. Another aspect of the present 
invention aUows users to create and share custom e-mail 
forms. The attributes of the custom form are stored in an 
e-mail property, along with the data that will be displayed in 
the custom form. FinaUy, another aspect of the present 
invention allows E-mail users to solicit input from a group 
of recipients by providing predetermined choices for their 
response. Each recipient repHes to the original query by 
selecting a response. When the sender receives the replies, 
the response is automatically tallied and easily available to 
the sender. 

The foregoing system may conveniently be implemented 
in a program module or program that is based upon the flow 
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charts and state diagrams in FIGS. 9, 10, 13, 16, 17 18, 22, 
24, 29, 32, 33 and 34. No particular programming language 
has been described for carrying out the various procedures 
described above because it is considered that the operations, 
steps, and procedures described above and iUustrated in the 
accompanying drawings are sufiSciently disclosed to permit 
one of ordinary skill in the art to practice the present 
invention. Moreover, there are many computers and oper- 
ating systems which may be used in practicing the present 
invention and therefore no detailed computer program could 
be provided which would be applicable to all of these many 
different systems. Each user of a particular computer wiU be 
aware of the language and tools which are most useful for 
that user's needs and purposes. 

The present invention has been described in relation to 
particular embodiments which are intended in aU respects to 
be illustrative rather than restrictive. Alternative embodi- 
ments will become apparent to those skiUed in the art to 
which the present invention pertains without departing from 
its spirit and scope. Accordingly, the scope of the present 
invention is defined by the appended claims rather than the 
foregoing description. 
What is claimed is: 

1, In an electronic mail system, a method for resolving a 
display name associated with an intended recipient of a 
message item, comprising the steps of: 

receiving in an address field said display name; 

determining whether said display name uniquely matches 
one of a plurality of registered users of said electronic 
mail system; and 

in response to said display name uniquely matching one 
of said registered users, displaying in said address field 
recipient data corresponding to said matching regis- 
tered user. 

otherwise, displaying ambiguous address data in said 
address field, 

wherein said step of determining whether said display 
name uniquely matches one of a plurality of registered 
users is processed in the background whUe a user 
composes the remainder of said message item. 

2. The method recited in claim 1, further comprising the 
steps of: 

receiving in said address field first user input correspond- 
ing to said ambiguous address data; 

displaying, in response to said first user input, a list of 
registered users corresponding to said ambiguous 
address data; 

receiving second user input corresponding to a selected 
one of said displayed list of registered users; and 

in response to said second user input, displaying in said 
address field recipient data corresponding to said 
selected registered user. 

3. ITie method recited in claim 2, further comprising the 
step of CTeating a nickname entry in a memory cache, the 
nickname entry characterized by said display name being 
associated with said selected registered user. 

4, In an electronic mail system, a method for using 
nicknames to resolve the name of an intended recipient of a 
message item, comprising the steps of: 

receiving in an address field a display name associated 

with said intended recipient; 
determining whether said display name corresponds to a 

previously stored nickname stored in a memory cache; 
in response to said display name corresponding to said 

previously stored nickname, displaying in said address 
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field nickname data corresponding to a registered user 
of said electronic mail system associated with said 
previously stored nicknanie; 

otherwise, determining whether said display name 
uniquely matches one of a plurality of registered users 5 
of said electronic mail system; and 

in response to said display name uniquely matching one 
of said registered users, displaying in said address field 
recipient data corresponding to said matching regis- 
tered user, 

otherwise, displaying ambiguous address data in said 
address field wherein said step of determining whether 
said display name corresponds to a previously stored 
nickname stored in a memory cache is processed in the 
background while a user composes the remainder of 
said message item. 

5. The method as recited in claim 4, wherein said ambigu- 
ous address data comprises said display name and predeter- 
mined indicia. 

20 

6. The method as recited in claim 4, wherein said nick- 
name data comprises at least a portion of a name of said 
registered user and predetermined indicia. 

7. The method as recited in claim 4, wherein recipient data 
corresponding to said matching registered user comprises at ^5 
least a portion of a name of said matching registered user. 

8. The method as recited in claim 4, wherein said steps of 
determining whether said display name corresponds to a 
previously stored nickname and determining whether said 
display name uniquely matches one of a plurality of regis- 
tered users are performed while a user composes the remain- 
der of said message. 

9. The method as recited in claim 4, further comprising 
the steps of: 

' receiving in said address field first user input correspond- 35 
ing to said ambiguous address data; 
displaying, in response to said first user input, a list of 
registered users corresponding to said ambiguous 
address data; 

receiving second user input corresponding to a selected 40 
one of said displayed list of registered users; and 

in response to said second user input, displaying in said 
address field recipient data corresponding to said 
selected registered user. 

10. The method as recited in claim 9, further comprising 
the step of creating a nickname entry characterized by said 
display name being associated with said selected registered 
user. 

11. The method as recited in claim 4, further comprising 
the steps of: 

receiving in said address field first user input correspond- 
ing to said nickname data; 

displaying, in response to said first user input, a list of 
registered users corresponding to said nickname data; 

receiving second user input corresponding to a selected 
one of said displayed list of registered users; and 

in response to said second user input, displaying in said 
address field recipient data corresponding to said 
selected registered user. 60 

12. The method as recited in claim 11, further comprising 
the step of updating a nickname entry in which said display 
name is stored in association with said selected registered 
user. 

13. A computer system for using nicknames to resolve the 65 
name of an intended recipient of a message item, compris- 
ing: 
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a central processing unit (CPU); 
an input device connected to said CPU; 
a display device coupled to said CPU; 
cache memory connected to said CPU; and 
memory coupled to said CPU for storing a program 
module; 

said CPU, responsive to instructions from said program 
module, being operative to: 

receive from said input device a display name indica- 
tive of said intended recipient, said display name 
being entered in an address field displayed on said 
display device; 

determine, in the background, whether said display 
name corresponds to a previously stored nickname 
stored in said cache memory; 

in response to said display name corresponding to said 
previously stored nickname, display in said address 
field nickname data corresponding to a registered 
user associated with said nickname; 

otherwise, determine whether said display name 
uniquely matches one of a plurality of registered 
users of said electronic mail system; and 

in response to said display name uniquely matching one 
of said registered users, display in said address field 
recipient data corresponding to said matching regis- 
tered user, 

otherwise, display ambiguoiis address data in said 
address field. 

14. The computer system recited in claim 13, wherein said 
ambiguous address data comprises said display name and 
predetermined indicia. 

15. The computer system recited in claim 13, wherein said 
nickname data comprises at least a portion of a name of said 
registered use and predetermined indicia. 

16. The computer system recited in claim 13, wherein 
recipient data corresponding to said matching registered user 
comprises at least a portion of a name of said matching 
registered user. 

17. The computer system recited in claim 13, wherein said 
CPU is further operative to: 

receive in said address field first user input corresponding 

to said ambiguous address data; 
display, in response to said first user input, a list of 

registered users corresponding to said ambiguous 

address data; 

receive second user input corresponding to a selected one 
of said displayed list of registered users; and 

in response to said second user input, display in said 
address field recipient data corresponding to said 
selected registered user 

18. The computer system recited in claim 17, wherein said 
CPU is further operative to create a nickname entry char- 
acterized by said display name being associated with said 
selected registered user. 

19. The computer system recited in claim 13, wherein said 
CPU is further operative to: 

receive in said address field first user input corresponding 

to said nickname data; 
display, in response to said first user input, a list of 

registered users corresponding to said nickname data; 
receive second user input corresponding to a selected one 

of said displayed list of registered users; and 
in response to said second user input, display in said 

address field recipient data corresponding to said 

selected registered user 
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20. The computer system recited in claim 19, wherein said 
CPU is further operative to update a nickname entry in 
which said display name is stored in association with said 
selected registered user in cache memory. 

21. A computer- readable medium on which is stored a 5 
computer program for resolving a display name associated 
with an intended recipient of a message item, said computer 
program comprising instructions which, when executed by a 
computer, perform the steps of: 

receiving in an address field said display name; 
determining whether said display name uniquely matches 

one of a plurality of registered users of said electronic 

mail system; 

in response to said display name uniquely matching one 
of said registered users, displaying in said address field 
recipient data corresponding to said matching regis- 
tered user; 

otherwise, displaying ambiguous address data in said 
address field; 
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receiving in said address field first user input correspond- 
ing to said ambiguous address data; 

displaying, in response to said first user input, a list of 
registered users corresponding to said ambiguous 
address data; 

receiving second user input corresponding to a selected 

one of said displayed list of registered users; and 
in response to said second user input, displaying in said 
address field recipient data corresponding to said 
selected registered user, wherein the step of determin- 
ing whether said display name uniquely matches one of 
a plurality of registered users of said electronic mail 
system is processed in the background while a user 
composes the remainder of said message item. 
22. The computer-readable medium recited in claim 21, 
further comprising the step of creating a nickname entry 
characterized by said address data being associated with said 
selected registered user. 
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